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Section  1  Executive  Summary 

The  Office  of  the  Director  of  Defense  Information  (DDI)  initiated  the  Functional  Process  Improvement 
(FPI)  Business  Rules  Requirements  Definition  effort  with  a  Data  Model  Planning  Workshop  in  January 
1993.  The  workshop  team  determined  that  information  flows  identified  in  the  FPI  Enterprise  Activity 
Model  were  open  to  interpretation.  These  flows  were  not  rigorous  nor  robust  enough  to  address  specific 
data  needed  for  FPI,  e.g.,  cost  elements.  An  engineering  approach,  such  as  data  modeling,  was  needed, 
breaking  information  down  into  reusable  and  shareable  components,  i.e.,  data,  available  for  any  level  of 
discussion.  The  workshop  team  outlined  a  data  modeling  effort  to  augment  the  FPI  Enterprise  Activity 
Model,  exploring  the  data  and  business  rules  of  FPI  process.  Business  rules  are  phrases,  captured  in  data 
models,  which  identify  constraints  effecting  business  processes.  Whether  or  not  they  are  currently 
defined,  every  organization  has  a  set  of  standing  business  rules.  These  rules  cover  things  and  concepts 
which  members  of  the  organization  require  knowledge  of  as  well  as  a  description  of  those  things  or 
concepts.  These  things  and  concepts  (people,  places,  objects,  events,  states,  ideas  or  pairs  of  things)  are 
called  entities.  The  entities  and  their  respective  relationships  comprise  the  business  rules. 

The  FPI  Business  Rules  Requirements  Definition  was  conducted  in  three  phases:  a  planning  workshop, 
which  merged  some  related,  available  data  models  as  a  pro  forma  for  downstream  modeling;  a  modeling 
workshop,  which  built  the  initial  FPI  Integrated  Data  Model  and  identified  issues  requiring  further 
analysis;  and  a  validation  workshop,  which  included  experienced  FEA  practitioners  who  reviewed  model 
accuracy  regarding  their  requirements,  and  which  concluded  with  a  series  of  issue  resolution  sessions. 

This  data  modeling  effort  focused  on  cost  elements  and  their  relationships,  and  established  linkages 
between  Functional  Economic  Analysis  (FEA)  and: 

•Office  of  Management  and  Budget  IT  43  Series  reporting  requirements  (meshing 
Comptroller  and  C3I  viewpoints) 

•Functional  and  Automated  Information  System  review  requirements  (PA&E  and  C3I) 
•Functional  management  requirements  (All  OSD) 

•Acquisition/Defense  Acquisition  Board  requirements  (Acquisition,  PA&E,  and  C3I) 

In  keeping  with  the  principles  of  the  Corporate  Information  Management  (CIM)  initiative,  the  FPI 
Business  Rules  Requirements  Definition  workshop  team  has  provided  a  means  for  functional  managers 
to  collect  cost  data  for  these  separate  yet  similar  requirements  once,  and  use  it  many  times. 

The  focus  on  cost  element  was  complemented  by  other  modeling  themes,  including: 

•Performance  measurement 

•Recurring  activity  resource  consumption  (IDEFO  activity  mechanisms). 

•Initiative,  or  one-time,  resource  consumption. 

•Cost  drivers  (IDEFO  activity  controls). 

•Linking  initiatives  to  recurring  activities  (cost/benefit  accountability). 

These  themes  organized  the  team’s  analysis  during  the  workshop.  Once  the  results  were  available,  the 
team  built  three  new  sets  of  information.  One  set  of  topical  area  views  chops  the  model  into  manageable 
dialogues,  e.g. ,  the  association  between  drivers  and  performance  measures.  Another  set  organizes  entities 
under  different  information  object  areas,  e.g.,  the  entities  supporting  OMB  IT  43A-1C1  reporting.  The 
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other  set  organizes  entities  into  abstractions  that  highlight  improvements  in  the  FPI  process,  e.g.,  tying 
performance  measures  to  strategic  goals. 

The  observations  culminating  from  these  workshops  include  recommendations  on  the  addition  and 
clarification  of  guidance  to  those  performing  Functional  Process  Improvement.  Working  with 
representatives  from  the  Institute  for  Defense  Analysis  (IDA),  the  team  recommended  incorporating 
changes  into  version  3.0  of  the  Functional  Economic  Analysis  Model,  anticipated  for  release  during  the 
fall  of  1993. 

The  next  step  for  the  FPI  Integrated  Data  Model  is  the  validation  of  the  model  through  pilot  projects  this 
summer  and  fall.  These  pilot  projects  will  continue  the  validation  and  extended  attribution  of  data 
requirements  represented  in  the  FPI  Integrated  Data  Model. 

The  model  documentation,  contained  in  the  appendices  of  this  report,  will  be  provided  electronically  to 
DISA-CIM  for  inclusion  in  a  data  repository.  DISA-CIM  becomes  the  model’s  custodian  at  that  point. 

The  consensus  supporting  the  data  model  and  the  new  thinking  resulting  from  this  effort  are  solids  step 
in  simplifying  the  FPI  process  and  its  information  requirements,  and  in  paving  the  way  for  increased  FPI 
automated  preparation  using  shared  functional  and  financial  data. 
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Section  2  Introduction  &  Project  Plan 
2.1  Background 

On  1  October  1992,  the  Department  of  Defense  Instruction  (DODI)  8020. 1-M  (draft)  initiated  the 
formation  of  the  Functional  Process  Improvement  Program  (FPIP)  for  the  Department  of  Defense  (DoD). 
This  program  was  established  as  a  method  for  eliminating  redundant  processes  and  redundant  data 
infrastructures.  The  FPEP  is  also  a  tool  for  process  re-engineering  to  eliminate  inefficiencies,  in 
accordance  with  the  principles  promoted  through  the  Corporate  Information  Management  (CIM)  initiative. 
Structured  methods  and  techniques  for  analyzing  and  recommending  improvements  in  DoD  functional 
activities  have  evolved  through  the  experiences  of  the  functional  managers  pioneering  Functional  Process 
Improvement  within  DoD.  One  of  these  methods,  the  Functional  Economic  Analysis  (FEA),  examines 
current  business  processes,  develops  options  for  improvement  of  those  processes,  and  facilitates 
comparisons  of  the  cost  and  subsequent  savings  of  these  options. 

As  various  groups  within  DoD  prepared  FEAs  for  the  first  time,  inconsistencies  arose  in  the  meanings 
of  types  of  information  (e.g.,  improvement  opportunities,  models,  performance  measures)  and  how  they 
are  interrelated.  This  is  particularly  true  in  the  area  of  costs. 

It  is  very  difficult  to  relate  cost  elements  to  the  specific  functional  activities  addressed  in  FPI  Budgets 
reflect  DoD  programs,  and  tend  to  aggregate  costs  at  a  high  level.  Acquisition  costs  are  arranged  by 
investment  and  life  cycle  phase.  Functional  activities  do  not  directly  align  to  programs,  investment,  or 
life  cycle  phases,  and  are  less  aggregated  than  typical  budgets.  Currently,  there  is  no  clear  or  standard 
way  to  resolve  these  differences.  These  translations  of  budget  to  activity  costs,  and  activity  to  acquisition 
costs,  result  in  loss  of  accountability  and  accuracy. 

To  resolve  some  of  the  questions  involved  in  connecting  the  activity  costs  required  in  FEA  and  the 
conventional  budget  arrangements  such  as  Major  Automated  Information  System  Review  Council 
(MAISRQ,  Planning  Programming  Budgeting  System  (PPBS),  and  reporting  exhibits  such  as  the  IT  43, 
the  Office  of  the  Director  of  Defense  Information  (DDI)  began  the  development  of  a  FPI  Enterprise 
activity  model.  This  model  depicts  various  information  flows  feeding  to  or  resulting  from  the  FPI 
process.  Describing  these  information  flows  was  an  important  first  step  in  promoting  common 
understanding,  although  it  lacked  the  rigor  needed  for  sharing  information.  The  rigor  needed  is  provided 
by  semantic  data  modeling,  such  as  contained  in  the  IDEF1X  data  modeling  method. 

The  DDI  sponsored  the  FPI  Data  Modeling  Planning  Workshop  in  January  1993.  That  effort  identified 
the  scope  of  the  phases  that  followed,  and  identified  previous  data  modeling  efforts  performed  by  other 
DoD  sponsored  groups  that  included  subject  areas  of  interest  to  this  scope.  These  models  served  as  the 
starting  point  for  the  construction  of  the  initial  FPI  Integrated  Data  Model.  The  team  for  Phase  I  also 
examined  the  FPI  Enterprise  activity  model,  which  has  undergone  through  several  validation  sessions  and 
continues  to  be  updated  as  FPI  evolves.  The  group  examined  the  information  presented  in  the  FPI 
Enterprise  activity  model  to  ensure  that  the  data  it  represents  was  captured  in  the  data  model. 
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2.2  Workshop  Purpose/Mission 

The  primary  purpose  of  this  modeling  effort  is  to  identify  and  understand  the  shared  data  that  underlies 
and  provides  the  foundation  for  Functional  Process  Improv_ment,  and  to  identify  linkages  to  the  related 
processes  of  Economic  A  nalysis  (EA)  conducted  by  the  Major  Automated  Information  Systems  Review 
Council  (MAISRC)  and  the  IT  43  exhibit  reporting  process.  This  concept  of  focusing  the  data  to  meet 
the  needs  of  the  Functional  Manager  is  illustrated  in  Figure  2-1. 

The  FPI  Business  Rules  (B/R)  Requirements  Definition  Workshop  team  members  are  subject  matter  ana 
functional  experts  from  different  DoD  areas.  The  mission  of  the  FPI  B/R  team  is  to  create  the  FPI 
Enterprise  Data  Model,  identify  the  linkages  to  the  other  financial  processes,  make  recommendations 
regarding  the  resolution  of  identified  issues,  and  disseminate  this  guidance  to  the  Functional  Managers 
conducting  FPI. 


Universe 
of  Concepts 


Uses  of  Shared  Data 


Key  Values 


“As-Is”  Aspect 


PPBS 


MAISRC 


Data 
[Elements 


“Cost  Element” 
(Untying  Factor) 


User: 

Functional 
Manager 
doing  FPI 


|  Petfbrmamet 
Measures: 


Figure  2-1.  Data  Focused  From  Different  Perspectives 
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2.3  Participants 

The  FPI  Business  Rules  Requirements  Definition  Workshop  phases  were  led  by  Dave  Norem  of  the  DDI. 
The  core  team  for  the  overall  effort  consisted  of  the  following  individuals: 


Name 

Affiliation 

Phone  Number 

Fax  Number 

Jack  Cloos 

IDA 

703-845-2506 

703-845-2211 

Paul  Kaschak 

DISA-CIM 

703-285-5222 

703-285-5255 

Doug  McDonald 

DISA-CIM 

703-285-5212 

703-285-5255 

Dave  Norem 

DDI 

703-746-7911 

Joe  Romito 

LMI 

301-320-7439 

301-320-4701 

Table  2-1.  Core  Team 


Extended  team  members  participated  in  the  different  phases,  providing  subject  expertise  and  sharing 
their  experiences  in  doing  Functional  Econor  ic  Analysis.  The  following  people  participated  as 
subject  matter  experts  in  one  or  more  of  the  workshop  sessions: 


Name 

Affiliation 

Phone  Number 

Fax  Number 

Steve  Bagby 

SAFM-CA 

703-756-0335 

703-756-2625 

Lowell  Blagmon 

NCA 

703-746-2308 

703-746-2390 

LTC  Gary  D.  Duvall 

OASD  (HA),  MFIM-LOG 

703-756-5611 

703-756-8964 

Herb  Ewert 

SAIS-IDC 

703-695-5216 

703-6974235 

LCDR  Marcus  Foote 

SPAWAR 

703-602-0107 

703-602-5207 

Dean  Hansen 

D.  Appleton  Co.,  Inc. 

703-573-7644 

703-698-8219 

Dan  Hill 

SRA 

703-5584054 

Eddie  Jackson 

DISA/CIM/OTI 

703-756-7802 

703-756-5881 

Joseph  Jengehino 

HQDA,  SAFM-BUC 

703-697-6241 

703-614-8807 

Joe  Krushinski 

OUSD(A)  AP+PI 

703-697-8020 

Sharon  A.  Larson 

OASD(HA),  MFIM-LOG 

703-756-8780 

703-756-8706 

Table  2-2.  Extended  Team  Members 
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Name 

Affiliation 

Phone  Number 

Fax  Number 

Nancy  Lopez 

NISMIC 

703-602-2581 

Capt.  Tom  Malsack 

DLA 

703-5584026 

Jim  Markell 

Wizdom 

703-548-7900 

703-548-7902 

Mike  Medlock 

LMI 

301-320-7439 

301-3204701 

Rex  R.  Mshail,  Jr. 

DLA  (CAAI) 

703-274-1916 

Rick  Osseck 

ISI 

703-578-8359 

Janet  Ostriker 

Wizdom 

703-548-7900 

703-548-7902 

Jewel  Parker 

PROC  CIM 

703-285-6505 

703-285-6579 

Mike  Peter 

NISMC 

703-602-2581 

Dick  Pombrio 

PMA 

301-608-3400 

Jan  Rider 

DLA 

703-274-6184 

703-274-3964 

Larry  Robertson 

USACEAC 

703-756-2049 

703-756-7553 

Alec  Salerno 

IDA 

703-845-2506 

703-845-2211 

David  Sidvansky 

HQDA,  SAFM-FO 

703-693-5572 

Lt.  Col.  Harvey 

Sietsema 

OASD  (HA).  MFIM-LOG 

703-756-5611 

703-756-8964 

David  Smith 

SRA 

703-5584734 

Stan  P.  Smith 

HQDA,  SAIS-PPG 

703-614-0447 

703-697-1583 

Paula  C.  Spinner 

SAF/FMCE 

703-693-9346 

703-697-6904 

Tom  Strain 

OASD  (P&L)  LSSD 

703-2744765 

703-274-3970 

Mike  Thompson 

PROC  CIM 

703-274-8348 

703-617-7248 

CAPT  Mike  Tieman 

HQ  USAF/SCPP 

703-6954783 

703-614-0156 

Ron  Wilson 

OASD  (PA&E) 

703-693-3827 

703-693-3828 

Table  2-2.  Extended  Team  Members  -  Continued 
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The  workshop  phases  were  conducted  in  facilitated  modeling  and  validation  sessions.  Facilitation  and 
workshop  support  were  provided  by: 


Name 

Affiliation 

Phase  of  Project 

Ron  Batman 

D.  Appleton  Co.,  Inc. 

Phase  I 

Robin  Cleary 

SRA 

Phase  II 

Kelly  Fahey 

D.  Appleton  Co.,  Inc. 

Phases  I  and  II 

Howard  Gentle 

D.  Appleton  Co.,  Inc. 

Phase  II 

Ed  Maltese 

D.  Appleton  Co.,  Inc. 

Phase  0  (Planning  Workshop) 

Robert  Moravec 

D.  Appleton  Co.,  Inc. 

Phases  0,  I  and  II 

Alexis  Stevens 

D.  Appleton  Co.,  Inc. 

Phase  0  (Planning  Workshop) 

Table  2-3.  Facilitation  Team 


2.4  Project  Schedule 

The  project  was  conducted  in  three  phases:  the  Planning  Workshop  (Phase  0),  Phase  I,  and  Phase  II, 
illustrated  in  Figure  2-2. 


FPI  Data  Model 
Planning  Workshop 
(Phase  0) 


3  Weeks 


FPI  Business  Rules 

FPI  Business  Rules 

Requirements 

1  .  .  | 

Requirements 

Definition  Workshop 

m  1 

Definition  Workshop 
Phase  II 

i 

* 

6  Weeks 

8  Weeks 

Figure  2-2.  Project  Schedule 


2-5 


FPI  Business  Rules  Requirements  Definition  Workshop 


FPI  Business  Rules  Requirements  Definition  Workshop 


Approach 


Section  3  Approach 

The  FPI  Business  Rules  Requirements  Definition  project  was  conducted  in  three  phases.  The  first.  Phase 
0,  produced  the  project  plan  and  scope  for  the  subsequent  efforts.  Phase  I  was  devoted  to  constructing 
the  FPI  Enterprise  Data  Model  and  documentation  of  issues.  Phase  II  continued  in  accumulating  issues, 
and  examined  those  issues  to  provide  recommendations  ami  solutions.  Illustrated  in  Figure  3-1  is  an 
activity  model  constructed  to  depict  the  process  during  Phase  II  of  this  integration  project. 


PIMM  1  FPIP 
Data  Model 


VaHdats  FPIP 
Data  Modal 


Validated 
Data 
l  Modal 


Plata  1  Intertn  Report 
I  FPIP  AetWIty  Modal 


DoO  Enterprise  Modal 


Introduce  Ollier 
I  Conceptual 
1  ErtNes 


Expanded 
Data  Modal 


8amplB  PPB8,  FPI, 
MAI  SRC  Data 


Inst  anti  ate 
Erl  lues 


Candidate  Entitles 


Walk-Thru 

Process 

Examples 


Issue  Clarlficstlonr 
Guidance 


Issue  Resolution  Requirement 


Modelng  Tools  |  1  FaclltMlon  Team 


Figure  3-1.  FPI  B/R  Workshop  Activity  Model 


3.1  Phase  0 

The  Planning  Workshop  was  conducted  over  a  period  of  three  weeks.  The  team  reviewed  existing  data 
models,  created  by  various  government  and  commercials  organizations,  in  order  to  identify  those  which 
best  represented  the  subject  areas  related  to  the  mission  and  purpose  of  this  data  modeling  effort.  The 
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team  identified  the  scope  for  the  subsequent  efforts,  developed  a  project  plan,  and  produced  a  merged, 
pro  forma  model  that  included  seven  data  models  for  review  by  the  Phase  I  group.  These  data  models 
were: 


•  Functional  Economic  Analysis  (FEA)  Data  Model 

•  Activity  Based  Costing  (ABC)  Data  Model 

•  U.S.  Army  Corps  of  Engineers  (USACE)  Encyclopedia  Data  Model 

•  IDEF  Users  Group  Meta-Model 

•  U.  S.  Army  Financial  Management  Model 

•  Mobil  Organization  View 

•  EC  AC  Data  Model  -  Organization  View 

The  project  plan  identified  major  subject  areas:  PPBS  and  budgeting;  Information  Systems  and  the  Major 
Automated  Information  System  Review  Council’s  (MAISRC)  Economic  Analysis  (EA);  and. 
Activity /Organization.  The  team  anticipated  a  linkage  in  cost  information  within  these  topical  areas. 
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3.2  Phase  I 

During  the  first  week,  a  team  reviewed  the  seven  data  models,  and  chose  the  areas  that  best  represented 
the  business  rules  for  the  focus  areas.  The  team  developed  a  validation  plan  for  reviewing  the  topic  areas 
during  the  subsequent  weeks. 

It  is  the  "reuse”  of  these  data  models  that  enabled  the  group  to  accomplish  the  Phase  I  objectives  within 
the  six  week  timeframe.  The  core  team  reviewed  the  models  to  validate,  analyze  and  compare  the  entities. 
The  team  then  selected  the  models  and  specific  groups  of  entities  for  review  by  the  topic  area  experts 
during  the  following  weeks.  The  results  of  the  area  analyses,  outlined  below,  were  then  consolidated  to 
create  the  FPI  Data  Model. 

Activity/Organization  Area 

The  group  chose  the  IDEF  Users  Group  model  as  the  starting  point  for  the  Activity  area,  and  a 
combination  of  the  Mobil  and  ECAC  models  for  the  Organization  area.  The  team  created  the 
FPI  Data  Model  Activity/Organization  View  from  this  starting  point,  supplemented  by  ideas  from 
the  other  models  and  the  collective  expertise. 

The  group  also  created  the  FPI  Data  Model  Initiative  View,  using  portions  of  the 
Activity/Organization  View  and  the  FEA  Data  Model.  The  resulting  view  depicted  ideas  the  core 
team  wanted  to  the  IS  team  to  review,  and  included  a  preliminary  link  between  activities  and 
information  systems.  The  team  identified  the  Army  Financial  Management  model  as  the  starting 
point  for  the  PPBS  group  and  created  a  view  of  that  model,  eliminating  the  non-applicable  entities 
and  relationships. 

Information  Systems  Area 

Subject  Matter  Experts  (SMEs)  for  the  area  of  Information  Systems  reviewed  and  validated  the 
Activity/Organization  and  Initiative  Views.  The  group  also  examined  a  view  from  the  Army 
ODISC4  Data  Architecture  Strategic  Requirements  Anal>sis  Planning  (STRAP)  data  model.  The 
group  examined  the  entities  and  relationships  within  these  models,  and  created  a  view  to 
represent  the  IS  area.  The  IS  view  reflects  the  significant  entities  and  relationships  for 
Information  Systems,  and  the  business  rules  that  relate  IS  to  the  Activity/Organization  view. 

PPBS/Budgeting  Area 

The  PPBS  SMEs  validated  the  IS  view  in  the  third  week,  and  reviewed  the  Army  Financial 
Management  model  view.  The  Financial  Management  model  served  as  a  starting  point  for  the 
FPI  PPBS  View.  The  group  validated  the  findings  of  the  previous  groups,  and  chose  the  entities 
from  the  Financial  Management  model  that  best  represented  the  budgeting  area,  creating  the 
PPBS  View. 

The  three  topical  data  model  views  were  analyzed,  and  same  or  similar  entities  consolidated.  The  three 
views  were  integrated  to  form  the  FPI  Data  Model.  Issues  identified  during,  but  not  resolved  within,  the 
validation  process  were  consolidated  into  recommendations  for  Phase  II  of  the  data  modeling  effort. 
Analysis  of  the  integrated  view  yielded  further  discovery  of  topics  to  be  addressed  in  Phase  II. 
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The  PPBS  SMEs  validated  the  IS  view  in  the  third  week,  and  reviewed  the  Army  Financial 
Management  model  view.  The  Financial  Management  model  served  as  a  starting  point  for  the 
FPI  PPBS  View.  The  group  validated  the  findings  of  the  previous  groups,  and  chose  the  entities 
from  the  Financial  Management  model  that  best  represented  the  budgeting  area,  creating  the 
PPBS  View. 

The  three  topical  data  model  views  were  analyzed,  and  same  or  similar  entities  consolidated.  The  three 
views  were  integrated  to  form  the  FPI  Data  Model.  Issues  identified  during,  but  not  resolved  within,  the 
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Analysis  of  the  integrated  view  yielded  further  discovery  of  topics  to  be  addressed  in  Phase  II. 
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3.3  Phase  n 

Phase  n  began  with  a  session  devoted  to  further  exploration  of  the  issues  associated  with  the  data  model. 
The  circle  of  participants  in  the  FPI  Data  Model  was  expanded  to  include  subject  matter  experts  in  the 
model  topics  and  Functional  Managers  in  various  stages  of  FPI.  The  group  met  to  validate  the  FPI 
Integrated  Data  Model  and  explore  how  well  the  model  would  meet  the  IT  43  and  MAISRC  information 
requirements.  The  group  built  instance  tables  for  principal  entities,  to  ensure  that  the  keys  were 
accurately  depicted.  These  instance  table  examples  are  contained  in  Appendix  G  of  this  document. 

The  core  team  considered  this  validation  and  consensus  process  critical  to  the  success  of  this  effort.  The 
validation  process  brought  together  the  people  who  provide  the  guidance  on  how  to  perform  FPI  and 
FEA,  and  the  people  who  use  the  guidance  to  do  FPI  and  FEA.  The  Functional  Managers  provided 
feedback  on  their  experiences  with  FEA  and  with  the  processes  of  MAISRC  and  IT  43  reporting.  The 
feedback  from  these  users  provided  numerous  recommendations  on  the  simplification  of  FPI  guidance  and 
requirements. 

Validation  sessions  were  conducted  to  ensure  that  the  model  and  recommendations  would  meet  the 
multiple  needs  of  the  DoD  people  and  processes  depending  on  the  data.  Mr.  Ron  Wilson  from  PA&E 
participated  to  ensure  that  the  model  would  be  compatible  with  the  information  requirements  of  MAISRC. 
The  core  team  met  with  Mr.  Chuck  Cardiff  from  the  Comptroller’s  office  to  gain  knowledge  on  the  IT 
43  reporting  requirements,  ensuring  that  the  information  needed  for  these  reports  could  be  derived  from 
data  in  the  model.  The  team  also  met  with  Dr.  Tom  Frazier  and  Mr.  Alec  Salerno  of  IDA  to  discuss 
issues  that  were  related  to  the  FEAM  software.  The  FEAM  model  is  being  modified  based  on  the 
discussions  of  that  meeting. 

It  is  important  to  note  that  in  constructing  the  FPI  Integrated  Data  Model  the  group  did  not  build 
specifications,  but  instead  captured  requirements.  In  other  words,  the  key-based  model  was  not  built 
from  a  perspective  of  future  implementation.  The  model  was  constructed  for  the  purpose  of  capturing 
the  business  rules  and  data  requirements  in  FPI.  While  the  model  could  easily  serve  as  an  excellent 
starting  point  for  implementation,  the  group  recognized  the  need  to  fully  capture  and  define  requirements 
with  a  more  conceptual  intent. 

The  issue  areas  documented  in  this  session  and  in  Phase  I  were  consolidated  into  17  issue  areas.  These 
issue  areas  were  organized  into  logical  groupings,  and  meetings  were  conducted  for  further  modeling  and 
resolution  of  non-modeling  issues.  The  conclusions  resulting  from  issue  resolution  and  model  analysis 
are  documented  in  Section  5,  and  the  issue  tracking  documents  are  contained  in  Appendix  G. 
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Section  4  Functional  Manager’s  Perspective 

The  FPI  Integrated  Data  Model  employs  the  IDEF1X  modeling  techniques  to  define  the  process  in  a 
logical  manner,  supported  by  a  graphical  representation.  To  facilitate  ease  in  quickly  reading  and 
understanding  the  FPI  Data  Model,  the  model  has  been  depicted  in  this  section  in  two  graphical  forms: 
the  FPI  Executive  Integrated  Data  Model  View,  which  is  intended  to  be  an  "executive  summary"  for  the 
full  model;  and  the  Topical  Area  Views,  which  focus  on  specific  areas  of  interest  using  small  groups  of 
entities.  In  addition  to  the  graphical  representations  of  the  model,  this  section  contains  a  section  titled 
Object  Analysis  and  an  abstracted  collection  of  the  business  rules.  The  Object  Analysis  maps  the  data 
entities  to  the  areas  of  major  interest,  such  as  IT  43  exhibits.  The  Business  Rule  Abstraction  is  a  subset 
of  the  business  rules  which  impact  the  FPI  process  or  its  procedures,  e.g.,  improvement  opportunities 
must  tie  to  a  performance  measure. 

4.1  Data  Model  Semantics 

A  data  model  is  a  graphic  representation  of  an  organization’s  conceptual  schema.  That  is,  it  is  a 
representation  of  the  data  required  to  support  an  organization  in  performing  its  tasks,  as  well  as  the 
relationships  between  those  data  entities.  The  primary  purpose  of  a  data  model  is  to  assist  in  the 
documentation  and  mapping  of  information  requirements,  as  well  as  to  document  the  "Business  Rules". 
Business  Rules  are  phrases  which  identify  constraints  effecting  business  processes.  For  further 
information  or  assistance  in  reading  IDEF1X  data  models,  contact  the  CIM  Hotline. 

4.2  Why  IDEF1X? 

IDEF1X  has  proven  to  be  a  useful  and  powerful  tool  for  modeling  a  conceptual  schema,  or  a  neutral 
representation  of  shared  information  elements.  IDEF1X  provides  a  full  set  of  semantic  modeling 
capabilities  which  define  data  in  a  fully  normalized1  structure,  allowing  an  initial  model  to  be  extended 
without  altering  the  initial  set  of  entities,  relationships,  and  attributes.  IDEF1X  models  are  also  used  to 
automatically  generate  database  designs  and  data  integrity  control  logic. 

4.3  FPI  Executive  Data  Model  View 

The  FPI  Executive  Data  Model  View  depicted  on  the  following  page  is  an  entity-relationship  level  version 
of  the  FPI  Data  Model.  Many  of  the  category  entities  and  some  associative  entities  were  deleted  in  order 
to  facilitate  the  quick  understanding  of  the  primary  ideas  represented  in  the  model.  The  "executive  view" 
depicts  the  FEA  requirements  and  a  logical  linkage  between  those  requirements  and  the  DoD  financial 
structure.  The  complete  key-based  FPI  Integrated  Data  Model  is  contained  in  Appendix  B. 


'Normalization  is  the  process  of  reducing  information  and  its  supporting  data  down  to  its  non-redundant,  or 
"atomic”  level;  i.e.,  where  each  fact  is  captured  once  and  has  one  exact  meaning. 
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Figure  4-1.  FPI  Data  Model  Executive  View 
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4.4  Topical  Area  Views 

The  FPI  Integrated  Data  Model  was  examined  for  areas  of  interest  or  issues.  These  areas  were  divided 
into  seventeen  topical  areas,  and  the  data  model  was  abstracted  to  depict  the  entities  involved  in  each 
topical  area. 

1.  Improvement  Opportunity: 

The  FPI  Data  Model  defines  the  impact  and  importance  of  the  Improvement-Opportunity  to  the 
FPI/CIM  initiative.  The  representation  identifies  the  parameters  of  an  Improvement-Opportunity, 
previously  left  to  the  interpretation  of  a  workshop  team.  The  data  model  created  for  the  FEA 
Guidebook  showed  the  identifying  relationship  from  Performance-Objective  to  Improvement- 
Opportunity.  The  business  rule  stated  by  this  relationship  says  that  an  Improvement-Opportunity 
must  be  linked  to  a  Performance-Objective,  and  thus  a  Performance-Measure.  An  Improvement- 
Opportunity  depends  on  this  linkage  for  its  very  existence.  Thus,  an  Improvement-Opportunity  now 
has  a  defined  role  in  the  assessment  of  an  operation,  and  is  no  longer  simply  an  idea.  This  role  was 
very  different  from  previous  thinking.  The  core  team  concurred  and  adopted  the  concept  from  the 
FEA  data  model.  The  group  also  determined  that  an  Improvement-Opportunity  is  supported  by  one 
or  more  Functional-Requirements.  The  Functional-Requirement  entity  links  the  Improvement- 
Opportunity  to  the  implementation  of  an  Initiative. 

The  entity  Improvement-Opportunity-Impact  was  created  to  provide  a  means  to  show  the  many 
potential  impacts  associated  with  a  particular  Improvement-Opportunity.  A  category  entity  called 
External-Improvement-Impact  was  created  to  depict  the  impact  of  an  improvement  opportunity 
outside  the  realm  of  the  Service  or  Agency  performing  FPI.  The  external  impact  could  be  positive, 
such  as  a  cost  saving  to  another  Service  or  Agency;  or,  the  external  impact  could  be  negative,  e.g. 
a  rise  in  cost  to  another  Service  or  Agency.  In  this  way  those  external  impacts  could  be  tracked 
when  they  are  known. 
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2.  Driver  to  Cost  Pool 

A  cost  pool  or  Financial-Resource-Pool  is  a  "pot  of  money"  established  to  pay  for  the  expenses  of 
doing  a  particular  activity.  In  the  data  model,  this  cost  pool  is  linked  to  the  Activity-Driver  through 
the  associative  entity  Financial-Resource-Pool-Driver.  Essentially,  this  graphic  states  that  there  are 
reasons  (regulations,  procedures,  need,  etc.)  driving  the  accomplishment  of  an  activity,  and  thus  a 
specific  allocation  of  funds  is  established  to  pay  for  the  completion  of  the  activity.  Also  represented 
is  the  idea  that  an  Activity  can  have  more  than  one  Driver  (reason)  and  that  the  funds  may  come 
from  multiple  locations  to  pay  for  an  activity.  However,  each  Driver  will  have  a  direct  link  to  a 
specific  account  or  "pot  of  money".  From  an  accounting  perspective,  the  driver  creates  the  need  for 
a  pool.  Controls  cause  the  pools,  and  Mechanisms  drain  the  pool.  Whereas  the  drain  from  the  pool 
was  known,  the  idea  of  this  cause  is  new.  These  cost  pools  are  further  illustrated  in  Abstraction  8, 
and  the  relationships  of  each  pool  are  further  explored  in  Abstractions  10  and  12. 


The  entity  Activity-Workload  provides  the  means  to  link  the  driver  to  the  expected  overall  output 
of  an  activity  for  a  given  fiscal  year. 
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Activity-MooeFName  (FK) 
Activity-Model-Version-ID  (FK) 
Activity-Name  (FK) 


Cost-Driver 

'Driver-Designation  (FK) 
Activity-Model-Name  (FK) 
Actiirity-ModeFVefSion-ID  (FK) 
Activity-Name  (FK) 


Schedule-Driver 
rDriver-Designation  (FK) 

;  ActMty-Model-Name  (FK) 
i  Activity-Model- Version- 1 D  (FK) 
Activity-Name  (FK) 

c 
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3.  Driver  to  Performance  Measure 

A  Driver  or  Activity-Driver  is  the  reason  for  which  an  activity  is  performed.  This  portion  of  the  data 
emphasizes  that  the  reason  an  activity  is  performed,  or  driver,  must  have  an  objective  that  can  be 
measured.  Thus,  an  organization  needs  to  be  able  to  manage  the  effectiveness  of  its  operation,  and 
can  do  so  by  reviewing  the  objectives  of  the  activity,  defined  by  its  performance  measures,  and 
assessing  whether  they  are  being  aided  or  burdened  by  a  particular  driver.  This  assessment  results 
in  the  ability  to  view  pitfalls  and  find  subsequent  resolutions  to  increase  the  efficiency  of  an  activity. 

The  key  attributes  Activity-Model-Name,  Activity-Model-Version-ID,  and  Activity-Name  migrate 
to  the  entity  Activity-Performance-Objective-Driver  from  both  parent  entities  (Activity-Performance- 
Objective  and  Activity-Driver),  and  must  have  the  same  value. 


I 

Performance-Objective _ 

Activity-Model-Version-ID  (FK) 
Activity-Model-Name  (FK) 
Performance-Measure-Name  (FK) 

Performance-Objective-Class 


□escribes 


Performance-Measure 
|  Performance-Measure-Name  1 


Defines 


Activity-Performanc^Objective 
'Activity-ModeFName  (FK)  ') 
Activity-Model- Version-ID  (FK)  ! 
Activity-Name  (FK) 
Performance-Measure-Name  (FK) 


Is  affected  by  | 


..  r 


j 


Describes 


Acttyity-Perfi 


tormanceSl 


bjective- Driver 


Activity-Model-Name  (FK) 
Activity-Model- Version-ID  (FK) 
Activity-Name  (FK) 
Driver-Designation  (FK) 
Performance-Measure-Name  (FK) 


Activity-Driver 
Driver-Designation  (FK)  “ 
Activity-Model-Name  (FK) 
Activity-ModeFVersion-ID  (FK) 
Activity-Name  (FK) 

Driver-Focus 


Describes 


Driver _ 

|  Driver-Designation 
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4.  Performance  Objective  to  Strategic  Goal 

The  model  states  that  a  Performance-Objective  must  be  either  a  Strategic-Performance-Objective  or 
Supporting-Performance-Objective.  A  Strategic-Performance-Objective  must  be  directly  related  to 
a  Strategic-Goal.  The  Supporting-Performance-Objectives  measure  some  action  of  the  business,  but 
are  not  directly  related  to  a  Strategic-Goal.  One  or  more  Supporting-Performance-Objectives  can 
make  up  a  Strategic-Performance-Objective.  In  conducting  FPI,  this  will  place  a  constraint  in  that 
the  Performance  Objectives  will  have  to  be  somehow  related  to  the  Strategic-Goal,  either  directly 
or  in  a  supporting  role.  This  business  rules  will  more  clearly  focus  the  Performance  Objectives  and 
subsequent  improvement  opportunities  on  the  changes  to  the  essential  processes. 

The  graphic  pictured  here  also  states  that  an  Activity-Model-Version  can  be  associated  with  one  or 
more  Strategic-Goal.  The  assumption  was  made  that,  within  CIM  and  FPI,  an  activity  model  would 
not  be  created  if  it  could  not  be  associated  with  a  Strategic-Goal. 


Performance-Measure 
I  Perfocmance-Measure-Name 


Activity; _ 

fActivity-Model-Version-ID 
Activity-Model-Name  (FK) 

DoD-Mission 
Activity-Model-Purpoie 
Activity-Model-Scope 
Activity-Model-Vievvpoint 
Activity-Model-Author-Name 
Activity-Modei-Creation-Oate 
|  Activity-Model-Revision-Date 
!  Root-Activity-Number 


Model-Version 


Describes 


i  k 

tance-OI 


Is  designed  to  meet 


Performance-^  bject  ive 
'Activity-Model- Vetsion-ID  (FK)  "1 

Acttvity-Model-Name  (FK) 
Performance-Measure-Name  (FK)  i 

Performance-Object  ive-Class 


Is  designed  to  meet 


Strategic-Goal 
Activity-Model- Version-ID  (FK)' 
Activity-Model-Name  (FK) 
StratagloGoaFName 


Jr 


1 


Supporting-Performance-Objective 
f  Activity  Model-Version-lb  (FK) 
Activity-Model-Name  (FK) 
Performance-Measure-Name  (FK) 

Strateglc-Performance-Measure-Name  (FK) 


Q  Performance-Objective-Class 


specifies  accomptistrmept  as 


comprises 


Strategic-Performance-Objedive 
Activity-Model- Version-ID  (FK) 

Activity-Model-Name  (FK) 

Strategle-Performance-Measure-Name  Performance  Measure-Name  (FK) 
Strategic-Goal-Name  (FK) 
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5.  Performance  Measure  to  Activities 

An  activity  must  have  a  criteria  by  which  the  effectiveness  of  that  activity  can  be  evaluated.  The 
FPI  Data  Model  identifies  this  criteria  as  Perform ance-Objecti ve,  which  has  specific  Performance- 
Measures.  The  graphic  illustrates  that  a  Model-Activity  that  has  been  modeled  in  compliance  with 
the  FPI  guidelines  has  one  or  more  Performance-Objectives.  This  illustration  completes  the 
management  circuit  that  requires  relevant  methods  to  evaluate  the  activities  within  an  organization. 

Performance-Measure  can  be  traced  to  an  activity  for  a  specific  model  through  the  Activity- 
Performance-Objective.  The  key  attributes  Activity-Model-Name  and  Activity-Version-ID  migrate 
to  Activity-Peiformance-Objective  from  both  Model-Activity  and  Performance-Objective.  These 
attributes  must  have  the  same  value. 


The  entity  Performance-Achievement  provides  the  means  of  assessing  the  expected  and  realized  work 
accomplished  for  a  given  fiscal  year.  This  is  where  the  functional  manager  can  go  back  to  the  FEA 
and  compare  the  actual  process  improvement  with  the  estimation. 


Activity-Version _ 

'  Activity  Name  (FK) 
Activity-Version-ID 


Model-Activity _ ' 

'  Activity-Model-Name  (FK) 
Activity-Model-Version-ID  (FK) 
Activity-Name  (FK) 

Defines  _  Activity-Version-ID  (FK) 

•  Is-Root-Activity 
Is-Parent-Activity 
EtTectivity-Focus 
Value-Added-Indtcator 


Performance-Objective 
'  Activity-Model- Version-IO  (FK) 
Activity-Model-Name  (FK) 
Performance-Measure-Name  (FK) 
Perlormance-Objective-Class 


Is  measured  as 


Is  described  in 

i 


Activity 


Activity-Name 


°J 


Accomplishes 


Defines 


Actiyity-PerfomTaMe-Objective 
'Activity-Model-Name  (FK) 
Activtty-ModeFVersion-ID  (FK) 

I  Activity-Name  (FK) 

\  Performanca-Measure-Name  (FK)  j 


Performance-Achievement 

-  'Activity-ModeFVersion-ID  (FK)  ' 

Activity-Model-Name  (FK) 
Performance-Measure-Name  (FK)  J 
Petformance-Objective-FiscaFYear  | 

Actual-Performance- Amount  ; 

Planned-Performance-Amount 


Performance-Measure 
Performance-Measure-Name  j 
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6.  Driver  to  Activity  Control 

This  abstraction  depicts  the  intertwining  relationships  between  controls  and  drivers  in  the  FPI 
process.  The  group  needed  to  be  able  to  connect  the  driver  at  the  Activity  level.  The  Activity- 
Control-Driver  was  used  to  depict  the  nature  of  this  relationship.  Through  this  associative  entity, 
multiple  instances  of  Activity-Control  can  be  associated  with  multiple  instances  of  Driver.  The 
relationship  states  that  an  Activity-Driver  describes  at  least  one  Activity-Control-Driver. 


Activily-ICO^  ® 
f  Activity-ModeFName  (FK)  ' 
i  Activity-ModeFVers  ion-IO  (FK)  I 
Activity-Name  (FK) 


ICOM-Name  (FK) 
ICOM-Type 


I 


ICOM-Type 


•  !  I 

Activity-Driver 

’  Driver-Designation  (FK)  'i 
Activity-ModeFName  (FK) 
Activity-Model-Version- 1 D  (FK) 
Activity-Name  (FK) 

1  Driver-Focus 


Describes 


Describes 


Activity-Control _ _ 

f  Activity-ModeFName  (FK) 
Activity-ModeFVersion-ID  (FK) 
Activity-Name  (FK) 
ControFName.lCOM-Name  (FK) 


Is  measured  as 


Activity-ControFDrtver 
Activity-ModeFName  (FK) 
Activity-ModeFVersion-ID  (FK) 
Activity-Name  (FK) 

•  ControFName  (FK) 
Driver-Designation  (FK) 


Driver 
Driver-Designation  j 
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7.  Initiative  Structure 

An  Initiative  is  a  one-time  task  that  implements  an  improvement  to  the  baseline  of  an  Activity.  The 
Initiative  entity  must  be  linked  to  an  Activity-Model-Version,  and  accomplishes  one  or  more 
Technical-Specifications. 

Activity-Model-Version  also  has  a  non-identifying  relationship  with  Initiative.  The  attributes  migrate 
to  the  non-key  position,  and  are  role  named  "Initiative-Activity-Model-Name"  and  "Initiative- 
Activity-Model-Version-ID".  This  relationship  states  that  an  Activity-Model-Version  can  be  used 
to  describe  the  steps  in  an  Initiative.  Through  these  dual  relationships,  the  Initiative  entity  tells  us 
both  the  Activity-Model- Version  realized  by  the  Initiative,  and  the  Activity-Model-Version  for  the 
Initiative  itself. 


Functional-Alternative  and  Initiative  are  the  parent  entities  for  the  associative  entity  Functional- 
Altemative-Initiative,  which  states  that  an  initiative  can  have  multiple  alternatives,  and  an  alternative 
can  be  a  part  of  more  than  one  initiative. 


Initiative  can  be  linked  to  a  Functional-Requirement  through  the  associative  entity  Technical- 
Specification.  The  associative  entity  allows  a  functional  requirement  to  serve  more  than  one 
initiative,  and  an  initiative  to  accomplish  more  than  one  functional  requirement 


Initiative 

'  Initiative-Designation  > 

Activity-Model-Name  (FK) 
Activity-ModeFVersion-ID  (FK) 

Initiative-Major-System-Designation 

Initiative-Start-Date 

Initiative-Required-Complelion-Date 

Initiative-Acceptance-Criteria 

Initiative-Type 


Technical-Specification 
'  Activity-Model- Version-ID  (FK) 
Functional-Requirement-Designation  (FK) 
Activity-Model-Name  (FK) 
Performance-Measure-Name  (FK) 
Armmnli«he«  Improvement-Opportunity-Designation  (FK) 
Accomplices^  Initiative-Designation  (FK) 

Component-Name  (FK) 

Organization-ID  (FK) 

T  echnicaFSpecifpcation-Perfomnance-Criteria 
TechnicaFSpecification-Acceptance-Criteria 


Is  selected  as 


Describes  the  steps  in 
:  Is  realized  as 


FunetionaFAItematiye-lnitiative 
'Activity-Model- Version-ID  (FK) ' 
Initiative-Designation  (FK) 
Alternative-Designation  (FK) 
Activity-Mode  1-Name  (FK) 

g 

Is  changed  through 


Is  converted  into 


Act  ivity-MoSe  I- Version 
'Activity-Model- Verslon-ID 
Activity-Model-Name  (FK) 

!  DoD-Mission 
I  Activity-ModeFPurpote 
I  Activity-Model- Scope 
i  Activity-Model- Viewpoint 
i  Acth/ity-Modei-Author-Name 
!  ActMty-ModeFCreation-Oale 
Activtty-ModeFRevtsion-Oate 
I  Root-Activity-Number 


Depicts  the  To  Be  state  of 


F  undionaFAItemative _ 

'Alternative-Designation  "'] 
Acbvity-ModeFVarsion-ID  (FK) 


(FK) 


[ FuncttonaFAItemative-Status  j 

^ _ > 


F  unctjonaFRequjrement _ 

FunctnnaFRequirement-Designation  1 
Activtty-ModeFName  (FK) 
Activity-ModeFVersion-ID  (FK) 
Performance-Measure-Name  (FK) 
Improvement-Opportunity-Designation  (FK) 
Component-Name  (FK) 

Organization-ID  (FK) 
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8.  Initiative  Activities 

An  Initiative  is  achieved  through  one  or  more  Initiative- Activities.  The  non-identifying  relationship 
from  Activity-Version  to  Initiative-Activity  migrates  with  a  split  key;  the  Activity-Name  migrates 
to  key  position  in  Initiative-Activity  and  is  role  named  "Initiative-Activity-Name".  The  Activity- 
Version-ID  is  not  necessary  to  uniquely  identify  an  Initiative-Activity  and  migrates  to  non-key 
position. 

Initiative- Activity-Link  was  created  to  provide  information  about  the  sequencing  of  Initiative- 
Activities.  The  two  identifying  relationships,  succeeds  and  precedes,  provide  role  named  keys  using 
"Succeeding"  or  "Preceding".  In  this  way,  the  sequential  order  of  Initiative-Activities  can  be 
determined.  A  category  was  established  for  Initiative- Activity,  using  the  attribute  Initiative-Activity- 
Milestone-Indicator.  If  an  Initiative-Activity  is  a  milestone  in  the  implementation  of  an  Initiative, 
then  it  is  an  Initiative-Activity-Milestone.  The  status  of  that  milestone  can  be  tracked. 


Activity-Version 
(  Activity-Name  (FK)') 
!  Activity-Vets ion-ID  1 


Initiative 


•  • 


Initiative-Designation 
Activity-Model-Name  (FK) 
Activity-Model-Version-ID  (FK) 


L____ 


Initiative-Activil 


e-Activity 


6 


.  d. 


-  1 

Defines  _  _  J 

i 

Is  achieved  through 

1 

•  <i> 

Initiative-Major-System-Designation 
Initiative-Start-Date 
Initiative-Required-Completion-Date  i 
Initiative-Acceptance-Criteria 
Initiative-Type 


Initiative-Designation  (FK) 
Initiative-Adivity-Name.Activity-Name  (FK) 
Activity-Model- Version-ID  (FK) 
Activity-Model-Name  (FK) 


j  Accountable-Component-Name.Component-Name  (FK) 
Accountable-Organization-ID.Organization-ID  (FK) 

1  Activity-Version-IO  (FK) 

Initiative-Activity-Cycle-Time 
;  Initiative-Activity-Performance-Criteria 
Initiative-Activity-Milestone-Indicator 


Initiative-Activity-Link _ _ 

f  Succeeding-lnitiative-Designatibn.initiative-Designation  (FK)  ' 

Preceding-lnitiative-Designation.lnitiative-Designation  (FK) 
Preceding-lnitiative-Activity-Name.lnitiative-ActMty-Name  (FK)  i 

^  Preceding-Process-Activity-Model- Vers  ion-ID.  Activity-Model- Version-ID  (FK)  | 
Preceding-Process-Activity-Model-Name.Activity-Model-Name  (FK) 

Precedes  J  Succeeding-lnitiative-Activity-Name  Initiative-Activity-Name  (FK)  i 

i  Succeed  in  g-Process-Act  tv  ity-Model-Version-IDActivity-Model- Vers  ion-ID  (FK)  I 
Succeeding-Process-Activity-Model-Name.Activity-Model-Name  (FK)  I 


Succeeds 


T" 


J 


Qlnitiative-Activity-Mileston  e-Indicator 


Initiative-Activity-Milestone 
fl Initiative-Designation  (FK)  (AK1 ) 
Inltiatlve-Actrvity-Name  (FK) 
Activity-Model- Vers  ion-ID  (FK) 
Activity-Model-Name  (FK) 

Initiatlve-Activtty.Milestone-Status  (AK1 ) 
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9.  Financial  Resource  Pool 

The  Object-Class-Code  identified  in  Financial-Resource-Pool  refers  to  not  what  money  is  spent  on, 
but  how  it  is  spent.  The  nature  of  the  expense,  and  what  kind  of  dollars  were  spent  in  order  to 
achieve  the  outcome,  is  identified  here.  Object-Class-Code  moves  toward  natural  expense  categories. 
This  is  a  transition  point  to  get  to  the  cost  element  and  what  it  tries  to  accomplish.  The  closest 
PPBS  comes  to  the  idea  of  cost  category  or  spending  is  Object-Class-Code. 

Obligation  (an  accounting  idea)  catches  the  way  the  budget  is  actually  spent.  This  led  to  the  idea 
of  a  Financial-Resource-Pool.  The  linkage  in  PPBS  to  the  other  areas  of  the  FPI  model  is  in 
Financial-Resource-Pool.  Through  the  entity  Organization-Program-Element,  the  Financial-Resource- 
Pool  tracks  the  data  of  the  Appropriation  funding  the  pool. 

The  Financial-Resource-Pool  funds  four  specific  pools:  Initiative-Activity-Woik-Resource-Pool, 
Mechanism-Resource-Pool, Mechanism-Supply-Resource-Pool,  and  Initiative-Supply-Resource-Pool. 
Each  pool,  the  related  entities,  and  the  business  rules  surrounding  these  pools  are  presented  as  topical 
areas  within  this  section. 


Of  the  four  pools,  two  are  related  to  activity  or  recurring  expenses  and  two  to  initiative  or  investment 
expenses.  The  activity  and  initiative  sets  mirror  each  other.  For  each,  one  pool  depicts  internal  costs 
and  the  other  costs  for  goods  or  services  acquired  through  a  supplier  (may  be  another  DoD  Service/ 
Agency,  non-DoD  government,  or  contractor  as  depicted  in  topical  area  #11). 

Organ  rzation-Program-Elament _ 

'Component-Name  (FK)  ; 

Major-Force-Program-Name  (FK)  j  ' 

Program-Element-Name  (FK)  I 

Organization-ID  (FK) 

Funding-Source-Fiscal-Year  (FK) 

Funding-Source-Purpose  (FK) 


Mechanism-Resource-Pool 


Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 
Object-Class-Code  (FK) 
Activity-Model-Name  (FK) 
Activity-Model- Vers  ion-ID  (FK) 
Activity-Name  (FK) 
Mechanism-Name  (FK) 
Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 


Describes 


. 


F  inanciaFResource-Pool 

f'rtnmnnnent.Nom*  rCKI 


Mechanism-Civilian-Labor-Amount 

Mechanism-Facility-Amount 

Mechanism-Material-Amount 

Mechanism-Military-Labor-Amount 

Mechanism-Other-Amount 

Meehan  ismEquipment-Amount 

Mechanism-General-Admin- Amount 


r. 


kFunds 

Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 
Object-Class-Code 
Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 

funds 

i 

i 

1 

Funds 

Funds 


Initiative-Supply-Resource-Pool 
Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 

Object-Class-Code  (FK) 
Initiative-Designation  (FIO 
Initiative-Activity-Name  (FK) 
Initiative-Activity-Component-Name  (FK) 
Initiative-Activity-Organization-ID  (FK) 
Activity-ModeFVersion-ID  (FK) 
Activity-Model-Name  (FK) 
Supplier-CAGE-Code  (FK) 

Agreement-ID  (FK) 

Fund  mg- Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 

ImtiativeSupply-MateriaP  Amount 
Initiative-Supply-Other-Amount 
Initiative-Supply-Equipment 
Initiative-Supply-General-  Admin-Amount 


Mechanism-Supply-Resource-Pool 
'Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 

Organization-ID  (FK) 

Object-Class-Code  (FK) 

Aethrity-Model-Name  (FK) 

Activity-Model- Vers  ion-ID  (FK) 

Activity-Name  (FK) 

Mechanism-Name  (FK) 

Supplier-CAGE-Code  (FK) 

Agreement-ID  (FK) 

Funding- Source-FiscaFYear  (FK) 

Funding- Source-Purpose  (FK) 
Mechanism-Supply-Requirement-Description  (FK) 


Mechanlsm-Suppty-Material- Amount 

Mechaniem-Supply-Other-Amount 

Mochantsm-Suppty-Equipment-Amount 

Meehan  (tnvSuppN-GerwraP  Admin- Amount 


4  4 

Initial  iva-Activtty-WorloResource-Pool 
Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 

Object-Class-Code  (FK) 
Initiative-Designation  (FK) 
InHiative-Activity-Name  (FK) 
InRiative-Activity-Component-Name  (FK) 
Initiative-Actlvlty-Organization-ID  (FK) 
Activity-Mod  el- Version-ID  (FK) 
Activity-Model-Name  (FK) 
Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 


1 


Initiative-Activity-Civilian-Labor-Amount 

Initiative-Activity-Facility-Amount 

Initiative-  Activity-Material-Amount 

Inltiative-Actwity  Military-Labor-Amount 

Initiative- Acttvtty-Ottier-Amount 

InWattve-Aetivty-Equipment-Amount 

Inlttatlve-Supply-Acbvty-GerwaMidmin-Amount 
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10.  Oiganizations  to  Appropriations 

This  abstraction  depicts  the  entities  that  tie  the  organizational  structure  to  the  budget  structure.  The 
model  states  that  Defense-Programs  may  have  Defense-Sub-Programs,  and  always  have  at  least  one 
Program-Element. 

A  Defense-Program  can  have  many  Appropriations,  and  a  Defense-Program  is  composed  of  many 
Program-Elements.  This  infers  a  Program -Element  can  be  related  to  many  Appropriations.  This  was 
questioned  by  group  members,  and  should  be  resolved  in  Phase  II. 

The  Organization-Program-Element  provides  the  linkage  to  Financial-Resource-Pool.  It  is  through 
this  linkage  that  the  resources  funding  activities  and  initiatives  can  be  traced  back  to  the  budget. 


Organization-Program-Element 
Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-IO  (FK) 
Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 


Comprises 


Organization-Appropriation 
''Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Organic  at  io  n-ID  (FK) 

H  Funding-Sou rce-FiscaPYear  (FK) 

!  Funding-Source-Purpose  (FK) 

l _ _ _ 


Is  funded  by 


,  ,  |  i  j  ! 

Organizational-Unit 
['Component-Name  (FK) 
i  Organization-ID  j 


!  Organization-Type 
!  UIC(AKI) 


1 


Describes 


I 

Funds 


Program-Element  _ 

Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name 

i  Defense-Sub-Program-Name  (FK) 
Program-Element-Code  (AK1) 


|  Comprises 

I 

Arranges  work  and  missions  through 


Component  _ 

j  Component-Name  : 


1  Manages  resources  through 


Compris 


Defense-Program-Appropriation 
('Component-Name  (FK) 
i  Major-Force-Program-Name  (FK)  j 
Funding-Source-FiscaFYear  (FK)  L  Funds 
Funding-Source-Purpose  (FK)  T 


Requests  fundi  as 


Funding-Source 
Component-Name  (FK) 
Funding-Source-Fiscal-Year 
-  Funding-Source-Purpose 

Funding-Source-Type 


Comprises 


Defense-Sub-Program 
'Major-Force-Program-Name  (FKf 
Defense-Sub-Program-Name 


nto  rrn 


Is  divided  Into  management  focus  areas  as 


Defense-Program 


Is  funded  by  J 


(  )  Funding-Source-Type 


Appropriation-Fund- Source 


Major-Force-Program-Name 


Major-Force-Program-Number  (AK1) 


Component-Name  (FK) 
Funding-Soui 


Vrg-Source-FiscaFYear  (FK) 
Appropriation-Purpose.Fundlng-Source-Purpose  (FK) 


Appropriation-Llmrtatloo-Code 
Treasury-Symbol  (AK1) 
Appropriation-Title  (AK2) 


Revolving-Fund-Source 


[  Component-Name  (FK) 
Fundlng-Source-FlscaPYear  (FK) 
!  Funding-Source-Purpose  (FK) 
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11.  Supplier  Types 

Supplier  is  the  parent  entity  of  a  complete  category  consisting  of  three  category  entities:  Non-DoD- 
Govemment-Supply-Source,  Contractor-Supply-Source,  and  DoD-Component-Supply-Source.  The 
complete  category  indicates  that  a  supplier  must  be  one  of  these  three  types.  The  attribute  Supply- 
Source-Type  is  the  discriminator  for  the  category.  The  relationship  depicted  shows  that  the 
Organizational-Unit  can  serves  as  a  DoD-Component-Supply-Source.  The  Supplier  is  also  linked  to 
the  Agreement  through  the  Supplier- Agreement  entity.  The  use  of  this  entity  enables  each  supplier 
to  provide  services  through  more  than  one  agreement,  and  for  an  agreement  to  be  applied  to  more 
than  one  supplier.  Although  not  depicted  in  this  picture,  the  Supplier-Agreement  is  a  parent  entity 
to  the  Mechanism -Supply-Agreement  and  the  Initiative-Supply-Agreement,  providing  die  linkage  to 
the  recurring  and  one-time  activities  they  are  providing  products  or  services  to. 


Contractor-Supply-Source 
J'Supplier-CAGE-Code  (FK)' 
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12.  Initiative  Activity  Work  Resource  Pool 

This  pool  reflects  the  internal  funding  of  a  one-time,  or  investment,  activity.  An  Initiative-Activity- 
Work-Performer  is  the  individual  or  organization  that  is  allocated  to  or  accomplishes  a  project 
(Initiative- Activity).  The  Initiative- Activity  may  have  multiple  work  performers.  The  model 
captures  whether  or  not  the  work  performer  is  Information  Technology  related  using  a  category 
relationship.  The  focus  on  whether  or  not  a  work  performer  is  related  to  IT  was  determine  by 
questioning  whether  the  computer  is  there  because  the  person  is  there,  or  if  the  person  is  there 
because  the  computer  is  there.  For  example,  a  person  who’s  job  within  an  initiative  is  to  provide 
technical  support  on  an  information  system,  that  person  is  an  IT  related  cost.  If  the  person  uses  an 
information  system  to  perform  the  functional  task,  the  person  is  not  an  IT  related  cost. 


The  Initiative-Activity-Work-Resource-Pool  is  the  funding  source  for  the  work  performer,  and 
provides  the  link  back  to  the  budgeting  process.  The  non-key  attributes  reflect  the  IDA  FEA  Model 
software  cost  categories  as  reviewed  by  this  group. 


Initiative-Activity-Wortt-Performcr 


u. 

Initiative-Activity 


A 


Initiative-Designation  (FK) 
Initiative-Activity-Name. Activity-Name  (FK) 
Activity-Model- Vers  ion-ID  (FK) 
Activity-Model-Name  (FK) 


Accountable-Component-Name.Component-Name  (FK) 
Accountable-Organizat  ion-ID. Organ  ization-ID  (FK) 
Activity- Version-ID  (FK) 

Initiative-Activity-Cycle-Time 
Initiative-Activity-Performance-Criteria 
Initiative-Activity-Mile  stone-indicator 


Is  accomplished  by 


Initial  rveActivrty-Work-Resource-Pool 


Initiative-Designation  (Fig 
Initiative-Activity-Name  (FK) 
InitiaUve-Activity-Component-Name.Component-Name  (FK) 
Initiative-Activity-Organization-ID.Organlzation-ID  (FK) 
Actlvity-Model-Verslon-ID  (FK) 

Activity-Model-Name  (FK) 


Initiative-Aclivity-Lile-Cycle-Cost-Element-ID  (AK1) 
Initiative-IT-Focus 


Causes 


Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 

Otyect-Class-Code  (Fig 
Initiative-Designation  (FK) 
Initiative-Activity-Name  (FK) 
Initiative-Activity-Component-Name  (FK) 
Initiative-Activity-Organization-ID  (FK) 
Adivity-Modet-Verslon-ID  (FK) 

-#  Activity-Model-Name  (FK) 

Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 


Initiative-IT-Focus 


Initiative-Activity-Civilian-Labor-Amount 

Initiative-Activity-Facility-Amount 

InrtiativeActivity-MaterJal-Amount 

Initiative-Activity-Military-Labor-Amount 

Inltiatlve-Activtty-Other-Amount 

Initiative-Activity-Equipment-Amount 

Initiattve-Suppty-Activity-General-Admin-Amount 


Initiative-IT-Activity-PertOfTner _ _ 

Initiative-Designation  (FK) 
Initiative-Activity-Name  (FK) 
Initiative-Activity-Component-Name  (FK) 
Inltlative-Acttvlty-Organtzation-ID  (FK) 
Activity-Model-Version-ID  (FK) 
Activity-Model-Name  (FK) 
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13.  Initiative  Supply  Resource  Pool 

This  pool  depicts  the  funding  of  outside  resources  needed  to  perform  an  activity  for  an  initiative 
(one-time  or  investment  activity).  The  Initiative-Activity-Work-Performer  may  need  to  accomplish 
an  Initiative-Activity  through  an  outside  source,  the  Initiative-Supply-Agreement.  These  resources 
are  funded  through  the  Initiative-Supply-Resource-Pool.  This  in  turn  links  the  pool  back  to  the 
budget. 


The  Technical-Specification,  which  is  a  functional  requirement  defined  at  the  specific  level  of  detail 
needed  for  acquisition  or  implementation,  is  the  parent  entity  to  Technical-Supply-Requirement.  The 
Technical-Supply-Requirement  provides  a  greater  level  of  detail,  such  as  the  amount  of  a  specific 
supply  or  service  required.  A  work  performer  may  use  multiple  sources  to  satisfy  a  requirement,  and 
a  Technical-Supply-Requirement  may  be  satisfied  through  multiple  sources.  The  entity  Initiative- 
Supply-Assignment  represents  the  product  or  service  that  satisfies  the  requirement,  and  the  source 
supplying  it. 


'  I 


u 


•  I  • 


A 


Initiative-Activity 
(1 Initiative-Designation  (FK) 

I  Initiative-Activity-Name.  Activity-Name  (FK) 

I  Adivity-ModeFVersion-ID  (FK) 

|  Activity-Model-Name  (FK) 

!  Accountable-Component-Name.Component-Name 
Accountable-Organization-ID.Organization-lD  (FK) 

I  Activity-Verskm-ID  (FK) 

!  Initiative-Activity-Cycle-Time 
!  Initiative-Adivity-Performance-Criteria 
I  Initiative-Activity-Milestone-Indicator 


|  Is  accomplished  by 


■'i 


(FK) 


Initiative-Supply-Resource-Pool 
^Component-Name  (FK)  j 

Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 

Object-Class-Code  (FIG 
Initiative-Designation  (FK) 
Initiative-Activity-Name  (FK) 
Initiative-Activity-Component-Name  (FK)  I 
Initiative-Activity-Organization-ID  (FK)  ! 
Adivity-ModeFVersion-ID  (FK) 
Activity-Model-Name  (FK) 
Supplier-CAGE-Code  (FK) 

Agreement-ID  (FK)  | 

Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 


Initiative-Supply-Material-Amount 
Initiative-Supply-Other-Amount 
Initiative-Supply-Equipment 
Initiative-Supply-General-Admin-Amount  i 


Tectinical-Specificatran  ^ 

[  AdivHy-ModeFVersion-ID  (FK) 

1  Functional-Requirement-Designation  (FK) 

1  Activity-Model-Name  (FK) 
i  Performance-Measure-Name  (FK) 
Improvement-Opporlunity-Designation  (FK) 
Initiative-Designation  (FK) 

I  Component-Name  (FK) 

Organization-ID  (FK) 

j  TechnicaFSpecification-Performance-Criteria 
,  Technical-Specification-Acceptance-Criteria 


Initiative-Act  ivity-Work-^erfOTner 

Initiative-Designation  (FK)  'j 

Initiative-Activity-Name  (FK) 

Initiative-Adivity-Component-Name.Component-Name  (FK)  j 
Initiative-ActMty-Organization-ID  Organization-ID  (FK) 
Activity-ModeFVersion-ID  (FK)  t— 

Adivity-ModeFName  (FK) 


Initiatlve-Adivity-Llfe-Cycie-Cost-Element-ID  (AK1 ) 
Initlative-IT-Focus 


Initiative-Supply-Agreement 
f  Initiative-Designation  (FK) 
Initiative-Adivity-Name  (FK) 

Initial  rve-Adivity-Component-Name  (FK) 
Initiative-Adivity-Organization-ID  (FK) 
gets  ^  Adivity-ModeFVersion-ID  (FK) 

“  Adivity-Model-Name  (FK) 

Supplier-CAGE-Code  (FK)  j 

j  Agreement-ID  (FK)  , 


I 


satisfies  demand  thru 


Identities  j 


Initiative  Supply-Assignment 
'Initiative-Designation  (FK) 
InHiative-Adivity-Name  (FK) 
Initiattve-Adivity-Component-Name  (FK) 
Initiattve-Adivity-Organization-ID  (FK) 
Adivity-ModeFVersion-ID  (FK) 
Adivity-Modei-Name  (FK) 
Supplier-CAGE-Code  (FK) 

Agreement-ID  (FK) 
Supply-Requirement-Description  (FK) 
Performance- Measure-Name  (FK) 
Improvament-Opporhjnity-Designation  (FK) 
Component-Name  (FK) 

Organization-ID  (FK) 
Funcbonal-Raqulramant -Designation  (FK) 


satisfies  demand  thru-  - 


T  echnicaFSuppty-Requirement 
Adtvity-ModeFVersion-ID  (FK) 
i  Supply-Requirement-Descxiption 
Adivity-ModeFName  (FK) 
Performance-Measure-Name  (FK) 
Improvement-Opportunity-Designation  (FK) 
Initiative-Designation  (FK) 
Component-Name  (FK) 

Organization-ID  (FK) 

FundionaFRequirement-Designation  (FK) 
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14.  Mechanism  Resource  Pool 

The  Mechanism -Resource-Pool  is  the  funding  that  supports  the  internal  requirements  of  a  recurring 
activity.  The  Activity-Mechanism  is  funded  by  the  Mechanism-Resource-Pool,  which  links  back  to 
the  budget  dollars.  The  recurring  activity  dollars  flow  through  Activity-Mechanisms. 

The  Activity-Mechanism  may  be  depicted  as  a  type:  position,  organization,  or  Information 
Technology.  Because  this  is  an  incomplete  category,  an  Activity-Mechanism  may  not  be  one  of  the 
types  depicted.  An  Organization-Mechanism  can  be  further  categorized  as  being  IT  related.  This 
ensures  that  IT  resources  provided  by  another  organization  can  be  accounted  for,  thus  providing  the 
ability  to  more  completely  collect  the  IT-related  costs  for  those  functional  managers  required  to  use 
these  figures  in  other  processes,  such  IT  43  reporting  requirements. 


Activity-Mechanism 
Activity-ModeFName  (FK) 
Activity-ModeFVersion-ID  (FK) 
Activity-Name  (FK) 

Mechanism-Name  ICOM-Name  (FK) 

Mechanism-Type 

Activity-Mechanism-IT-Focus  i 


Is  funded  by 


Mechanism-ResourcnPool 
^Component-Name  (FK) 
Majof-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 
Organization-ID  (FK) 
Object-Class-Code  (FK) 

I  Activity-ModeFName  (FK) 

|  Activity-ModeFVersion-ID  (FK) 
Activity-Name  (FK) 

I  Mechanism-Name  (FK) 

|  Funding-Source-FiscaFYear  (FK) 
Funding-Source-Purpose  (FK) 

'  Mechanism-Civilian-Labor-Amount 
Mechanism-Facility-Amount 
:  Mechanism-MateriaFAmount 
Mechanism-Military-Labor-Amount 
!  Mechanism-Other-Amount 
:  Mechanism-Equipment-Amount 
:  Mechanism-GeneraFAdmin-Amount 


Mechanism-Type 


OrganSationaFUnit 
Component-Name  (FK) 
Organization-ID 


Organization-Type 
UIC  (AK1) 


'Comprises 


IT-Mechanism 

( Activity-ModeFName  (FK)  ' 
j  Activlty-ModeFVersion-ID  (FK) 
i  Activity-Name  (FK) 
i  Mechanism-Name  (FK) 


Organization-Mechanism 
Activity-ModeFName  (FK) 
Activity-ModeFVerslon-ID  (FK) 
Activity-Name  (FK) 

Mechanism-Name  (FK) 

Component-Name  (FK) 

Organization-ID  (FK) 

Organ  ization-Civilian-FulFTime-Equivalent 
Organization-Milit-ry-FulFTime-Equivalent 
Organization-Mechanism-Focus 


Is  represented  as 


Position-Mechanism 
Activity-ModeFName  (FK) 
Activity-ModeFVersion-ID  (FK)  I 
Activity-Name  (FK) 

Mechanism-N"-ie  (FK) 

Position-Nam*.  v  K) 

Position-Civilian-FulFTime-Equivalent 

Position-Military-FulFTime-Equivalent 

*  -  '  •  ' .  •' 


Needs 


Q  Organ  i 


lization-Mechanism-Foeus 


Is  represented  as 


Position 

Position-Name 


Describes 


IT-Organization-Mechanism 
f  Activity-ModeFName  (FK)  1 
|  Activlty-ModeFVersion-ID  (FK) ; 
1  Activity-Name  (FK) 
Mechanism-Name  (FK) 


Organization-Portion 
Position-Name  (FK) 
Component-Name  (FK) 
0  Organization-ID  (FK) 

l  '  .  ..‘“1  " 
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15.  Mechanism  Supply  Resource  Pool 

The  Mechanism -Supply -Resource-Pool  depicts  the  funding  that  supports  external  resources  required 
to  accomplish  a  recurring  activity.  The  Activity-Mechanism  can  have  more  than  one  requirement, 
and  the  requirement  can  be  met  through  the  agreement.  This  pool  is  analogous  to  the  Initiative* 
Supply-Resource-Pool,  although  the  relationships  are  less  complicated.  Typically,  replacements  (such 
as  replacing  a  old  PC)  are  funded  through  this  pool. 


Activity-Mechanism 


Activity-Model-Name  (FK) 
Activity-Model- Verslon-ID  (FK) 
Activity-Name  (FK) 
Mechanism-Name.lCOM-Name  (FK) 


I  Meehan  l*m-Type 
^  ActMty-Mechanism-iT-Focui 


places  an  acquisition  demand  as 


Mechanism-Supply-Requirement 
f Activity-Modet-Name  (FK) 
Activlty-Model-Version-ID  (FK) 
Activity-Name  (FK) 

B  t  Mechanism-Name  (FK) 


Meehan  ism- Suppiy-Requirement-Demcription 


Mechanlsm-Supply-Resource-Pooi 


Component-Name  (FK) 
Major-Force-Program-Name  (FK) 
Program-Element-Name  (FK) 

Organ  tratlorv-ID  (FK) 

Object-Class-Code  (FK) 

Activity-Model-Name  (FK) 

Activity- ModeFVerslon-ID  (FK) 

Activity-Name  (FK) 

Mechanism-Name  (FK) 

Suppller-CAGE-Code  (FK) 

Agreement-ID  (FK) 

Funding-Source-Fiscal-Year  (FK) 
Funding-Source-Purpose  (FK) 
Mechanism-Supply-Requirement-Description  (FK) 


Mechanism-Supply-Material-Amount 
Mechanlsm-Supply-Other-Amount 
Mechanism-Supply-Equipment-Amount 
Meehan  ism-Suppty-Genera  I- Admin- Amount 


.  is  funded  by 


is  satisfied  through 


Mechanism-Supply-Agreement _ 

'Activity-Model-Name  (FK) 

Activity-Model- Version-ID  (FK) 

Activity-Name  (FK) 

Mechanism-Name  (FK) 

Supplier-CAGE-Code  (FK) 

Agreement-ID  (FK) 

Mechanism- Supply-Requirement-Oescription  (FK) 
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16.  Ioitiative/Recuning  Activity  Linkage 

The  view  depicted  here  shows  how  the  completion  of  a  step  in  an  initiative  enables  die  improvement 
of  the  process,  thus  beginning  the  realization  of  savings.  The  entity  Model-Activity  has  three 
subtypes:  the  replacement,  discontinued,  or  introduced  activity.  The  replacement  activity  includes 
changed,  combined,  or  split  activities.  The  entity  Model-Activity-Transition-Link  provides  die  means 
to  track  how  the  activities  are  changed.  When  an  Initiative-Activity  is  complete,  it  triggers  die 
realization  of  these  changes. 


Modei-ActMty 


Inltlatlve-AC 


Activity-Model-Name  (FK) 
Activity-Model- Vers  lon-IO  (FK) 
Activity-Name  (FK) 


Activity-Version-ID  (FK) 

Is-Root-Adivity 

Is-Parent-Activity 

Effectivity-Focus 

Value-Added-Indicator 


Initiative-Designation  (FK) 
Initiative-Activity-Name  Activity-Name  (FK) 
Acdvtty-Modei-Version-ID  (FK) 

Activity- Model-Name  (FK) 


Aocountabie-Component-Name.Component-Name  (FK) 
Accountable-Oganizatlon-ID.Oraanization-ID  (FK) 
Activity-Version-ID  (FK) 

Inltiatlve-Actlvity-Cycle-Tkne 
Initiative- Acttvity-Performance-Crlteria 
Initiative- Activity-Milestone-Indicator 


trigger^  the^k^atiorrc 


QEffectivity-Foeus 


Replacement  Activity 


r 


triggers  the  realisation  of 


Activity-Model-Name  (FK) 
Activlty-Model-Verslon-ID  (FK) 
Activity-Name  (FK) 


Discontinued  Activity 


triggers  the  realisation  of 


1 


precedes 


Modei-Activtty-Transltlon-Link 


Activity-Modet-Name  (FK) 
Acttvty-Model-Version-ID  (FK) 
Activity-Name  (FK) 


Initiatlve-Oeslgnation  (FK) 

Initlative-Activtty-Name  (FK) 

Effective- Activity-Model- Version. Actlvity-ModeFVersion-ID  (FK)  I 


Introduced  Activity 


Activity-Model-Name  (FK) 

Succeeding- Activity-Mode  I- Version-IO 
Preceding-Activity-Model-Vorsion-IDAi 
Succeeding-ActivltyKName Activity-Name  (FK) 
Preceding- Acttvty-Nsme  Activity-Name  (FK) 


ActMty-Model-Verslon-ID  (FK) 
ictivtty-Modei-VerilorvIO  (FK) 


Initiative-Designation  (FK) 
Initiative- ActMty4lame  (FK) 


Activity-Model-Name  (FK) 
Activity-Model-Version-ID  (FK) 
Activity-Name  (FK) 


Initiative-Designation  (FK) 
InWativeArtvSy^lame  (FK) 
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4.5  Business  Rule  Abstractions 
Business  Rule  Affect  on  FPI  Process 

IDEFO  Activity  Mechanisms 

Ties  funding  to  Operational  Activities  life  cycle  phase.. 
Recognizes  activity  mechanisms  as  funding  pipelines. 

Related  Entities 

Activity-Mechanism 

IT-Mechanism 

IT  -Organization-Mechanism 

Mechanism-Resource-Pool 

Mechanism-Supply-Agreement 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Requirement 

Model-Activity 

Organization-Mechanism 

Position-Mechanism 


Baseline  Savings 

Firmly  links  completion  of  initiative  steps  (activities)  to  recurring  activities. 
Provides  path  to  those  accountable  for  the  initiative  activities. 

Addresses  effectivity  control/change  management. 

Related  Entities 

Discontinued  Activity 

Initiative 

Initiative-Activity 

Initiative-Activity-Link 

Introduced  Activity 

Model-Activity 

Model-Activity-Transition-Link 
Replacement  Activity 
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Drivers 

Establishes  cause/effect  relationships  between: 

Cost  drivers  and  performance  measures. 

IDEFO  activity  controls  and  cost  pools. 

Establishes  relationships  between  IDEFO  models  and  Activity  Based  Costing 

Related  Entities 
Activity-Control 
Activity-Control-Driver 
Activity-Driver 

Activity-Performance-Objective-Driver 

Activity-Workload 

Cost-Driver 

Driver 

Financial-Resource-Pool-Driver 

Performance-Driver 

Schedule-Driver 


Activity-Based  Initiative 

Introduces  concept  of  activities  to  initiatives  possibly  enabling  common  methods  and  development 
of  Bill  of  Activities/Materials. 

Provides  path  between  activity  model  version  effectivity  control  and  enabling  contracts,  etc. 


Related  Entities 
Activity-Model- Version 
Initiative 

Initiative  Supply-Assignment 

Initiative-Activity-Work-Resource-Pool 

Initiative-Activity-Milestone 

Initiative-Activity-Work-Performer 

Initiative-Activity 

Initiative-Activity-Link 

Initiative-IT-Activity-Performer 

Initiative-Supply-Agreement 

Initiative-Supply-Resource-Pool 

Model-Activity 

Performance-Objective 

Supplier-Agreement 
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Improvement  Opportunities 

Establishes  requirement  for  improvement  opportunities  meeting  performance  measures. 

Establishes  position  within  higher-level  contextual  activities  for  benefits  outside  functional  scope. 
Establishes  path  to  initiatives  through  functional  requirements  and  resulting  technical  specifications. 
Establishes  path  between  improvement  opportunities  and  activities. 

Related  Entities 

Activity-Model-Version 

Activity-Performance-Objective 

Extemal-Improvement-Impact 

Functional-Alternative 

Functional-Altemative-Initiative 

Functional-Requirement 

Improvement-Opportunity-Impact 

Improvement-Opportunity 

Initiative 

Model-Activity 

Non-Value-Added-Activity 

Performance-Objective 

Technical-Specification 

Value-Added-Activity 

Performance  Measurement 

Ties  performance  measures  to  strategic  goals. 

Establishes  tie  between  improvement  opportunities  and  initiatives. 

Establishes  relationship  to  activities  and  their  attributes,  e.g.,  activity  outputs  and  controls. 
Establishes  performance  measurement  in  support  of  functional  areas  and  activities. 

Related  Entities 

Activity-Control-Driver 

Activity-Model-Version 

Activity-Performance-Objective-Driver 

Activity-Performance-Objective 

Activity-Workload 

Functional  Activity 

Functional  Area 

Improvement-Opportunity 

Initiative 

Initiative-Activity 

Model-Activity 

Performance-Achievement 

Performance-Measure 

Performance-Objective 

Primary-Output 

Strategic-Goal 

Strategic-Performance-Objective 

Supporting-Performance-Objective 
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4.6  Object  Analysis 

The  Object  Analysis  correlates  areas  of  major  interest  with  the  entities  from  the  FPI  Integrated  Data 
Model.  This  section  is  provided  in  two  parts:  the  first  part  is  grouped  by  object  area,  listing  the  entities 
used  in  each;  the  second  part  is  grouped  by  entity,  referencing  the  object  areas. 

4.6.1  Object  Areas  and  the  Entities  They  Use 

OMB  43  Series 

OMB  IT  43  reporting  describes  funds  identified  for  information  technology  (IT)  development  and 
modernization  (43A1  series),  and  IT  operations  and  maintenance  (43A2  Series).  The  other  series  (4BC 
through  43F)  present  different  aspects  of  the  same  funding. 

43A  summarizes  detail  supporting  OMB  &  Congressional  reporting  threshold  of  $2M  in  IT  development 
and  modernization  expenditures. 

43A-1  is  development  and  modernization  costs  falling  within  threshold  costs  of  $25M-100M.  The  43 A- 1 
is  required  by  Congress  (since  1986)  and  is  now  required  by  OMB  as  a  formal  exhibit. 

Object  Area:  Entity: 

43  A- 1  Initiative 

43 A- 1  Initiative  Supply-Assignment 

43  A- 1  Initiative- Activity- Work-Resource-Pool 

43  A- 1  Initiative-Activity-Milestone 

43A-1  Initiative-Activity-Work-Performer 

43  A- 1  Initiative- Activity 

43  A- 1  Initiative-IT-Activity-Performer 

43  A- 1  Initiative-Supply- Agreement 

43  A- 1  Initiative-Supply-Resource-Pool 

43A-1A  identifies  each  major  system  undergoing  development  or  modernization. 

Object  Area:  Entity: 

43A-1A  Activity-Model 

43A-1A  Functional  Activity 

43A-1A  Functional  Area 

43A-1A  Functional  Alternative  Iinitiative 

43A-1A  Initiative 

43A-1A  Initiative  Supply- Assignment 

43  A- 1 A  Initiative- Activity- Work-Resource-Pool 

43A-1A  Initiative- Activity-Milestone 

43  A- 1 A  Initiative- Activity-W  ork-Performer 

43A-1A  Initiative-Activity 

43A-1A  Initiative-IT-Activity-Performer 

43A-1A  Initiative-Supply- Agreement 

43A-1A  Initiative-Supply-Resource-Pool 
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43A-1B  identifies  development  and  modernization  funds  spent  for  each  non-major  system. 


Object  Area: 

43  A- IB 

43A-1B 

43A-1B 

43A-1B 

43A-1B 

43A-1B 

43  A- IB 

43A-1B 

43  A- IB 

43A-1B 

43A-1B 

43A-1B 

43A-1B 


Entity: 

Activity-Model 
Functional  Activity 
Functional  Area 

Functional  Alternative  Iinitiative 
Initiative 

Initiative  Supply-Assignment 
Initiative-Activity-Work-Resource-Pool 
Initiative- Activity-Milestone 
Initiative- Activity-Work-Performer 
Initiative-Activity 
Initiative-IT-Activity-Performer 
Initiative-Supply-Agreement 
Initiative-Supply-Resource-Pool 


43A-1C  summarizes  other  miscellaneous  development  and  modernization  funds. 


Object  Area: 

43A-1C 

43A-1C 

43A-1C 

43A-1C 

43A-1C 

43A-1C 

43A-1C 

43A-1C 

43A-1C 


Entity: 

Initiative 

Initiative  Supply-Assignment 

Initiative-Activity-Work-Resource-Pool 

Initiative-Activity-Milestone 

Initiative-Activity-Work-Performer 

Initiative-Activity 

Initiative-IT-Activity-Performer 

Initiative-Supply-Agreement 

Initiative-Supply-Resource-Pool 


43A-1CI  reports  development  and  modernization  costs  by  CIM  functional  area. 


Object  Area: 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43A-1C1 

43  A- 1C  1 

43A-1C1 

43  A- 1C  1 

43A-1C1 


Entity: 

Activity-Model 
Functional  Activity 
Functional  Area 

Functional  Alternative  Iinitiative 
Initiative 

Initiative  Supply-Assignment 

Initiative-Activity-Work-Resource-Pool 

Initiative- Activity-Milestone 

Initiative-Activity-Work-Performer 

Initiative-Activity 

Initiative-IT-Activity-Performer 

Initiative-Supply-Agreement 

Initiative-Supply-Resource-Pool 
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43A-2  describes  the  operational  and  maintenance  funding  of  fielded,  or  baseline,  systems. 


Object  Area: 

43A-2 

43A-2 

43A-2 

43A-2 

43A-2 

43A-2 


Entity: 

IT-Mechanism  (indicates  system  designation) 

IT-Organization-Mechanism 

Mechanism-Resource-Pool 

Mechanism-Supply-Agreement 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Requirement 


43-2A  reports  operational  and  maintenance  funding  by  system  within  CIM  functional  area. 


Object  Area: 

43A-2A 

43A-2A 

43A-2A 

43A-2A 

43A-2A 

43A-2A 

43A-2A 

43A-2A 

43A-2A 


Entity: 

Activity-Model 
Functional  Activity 
Functional  Area 

IT-Mechanism  (indicates  system  designation) 

IT-Organization-Mechanism 

Mechanism-Resource-Pool 

Mechanism-Supply-Agreement 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Requirement 


43B  describes  funds  for  seven  spending  categories:  contracts,  acquisitions  that  relate  to  capital 
investments  items,  rental,  commercial  services,  etc.,  when  system  costs  exceed  $5M  over  the  FYDP.  43B 
satisfies  paperwork  reduction  act  for  five  year  acquisition  plan.  It  is  required  by  OMB,  and  is  reviewed, 
although  not  required,  by  Congress. 


Object  Area: 

Entity: 

43B 

Agreement 

43B 

Contractor-Supply-Source 

43B 

DoD-Component-Supply-Source 

43B 

IT-Mechanism 

43B 

Initiative 

43B 

Initiative  Supply-Assignment 

43B 

Initiative-Activity-Work-Performer 

43B 

Initiative-IT-Activity-Performer 

43B 

Initiative-Supply-Agreement 

43B 

Initiative-Supply-Resource-Pool 

43B 

Mechanism-Supply-Agreement 

43B 

Mechanism-Supply-Resource-Pool 

43B 

Mechanism-Supply-Requirement 

43B 

Non-DoD-Goverament-Supply-Source 

4-25 


FPI  Business  Rules  Requirements  Definition  Workshop 


Functional  Manager’s  Perspective 


43C  presents  a  narrative  summary  for  each  major  system,  including:  milestone  schedule,  project  manager, 
life  cycle  costs,  sunk  costs,  etc.  Similar  in  content  to  IRM  quarterly  reports. 

Object  Area:  Entity: 

43C  Discontinued  Activity 

43C  Functional-Requirement 

43C  IT-Mechanism  (indicates  system  designation) 

43C  IT  -Organization-Mechanism 

43C  Improvement-Opportunity-Impact 

43C  Improvement-Opportunity 

43C  Initiative  (indicates  system  designation) 

43C  Initiative  Supply-Assignment 

43C  Initiative-Activity-Work-Resource-Pool 

43C  Initiative-Activity-Milestone 

43C  Initiative-Activity-Work-Performer 

43C  Initiative-Activity 

43C  Initiative-Activity-Link 

43C  Initiative-IT-Activity-Performer 

43C  Initiative-Supply-Agreement 

43C  Initiative-Supply-Resource-Pool 

43C  Introduced  Activity 

43C  Mechanism-Resource-Pool 

43C  Mechanism-Supply-Agreement 

43C  Mechanism-Supply-Resource-Pool 

43C  Mechanism-Supply-Requirement 

43C  Replacement  Activity 

43C  Technical-Specification 


4-26 


FPI  Business  Rules  Requirements  Definition  Workshop 


Functional  Manager’s  Perspective 


43D  describes  Indefinite  Delivery,  Indefinite  Quantity  (IDIQ)  Contracts  meeting  a  threshold  of  $2M/FY, 
identifying  the  use  of  umbrella  contracts.  43D  is  a  collective  effort  of  the  contract  originator  and  various 
involved  users. 

Object  Area:  Entity: 

43D  Agreement 

43D  Contractor-Supply-Source 

43D  DoD-Component-Supply-Source 

43D  Initiative  Supply-Assignment 

43D  Initiative-Activity 

43D  Initiative-IT-Activity-Performer 

43D  Initiative-Supply-Agreement 

43D  Initiative-Supply-Resource-Pool 

43D  Mechanism-Supply-Agreement 

43D  Mechanism-Supply-Resource-Pool 

43D  Mechanism-Supply-Requirement 

43D  Non-DoD-Govemment-Supply-Source 

43D  Supplier 

43D  Supplier-Agreement 

43D  Technical-Supply-Requirement 

43E  tracks  software  design  activities,  summarizing  money  spent  on  Central  Design  Activities  (CDA). 
Congressional  reporting  threshold  is  $5M. 

Object  Area:  Entity: 

43E  Initiative  Supply-Assignment 

43E  Initiative-Activity-Work-Resource-Pool 

43E  Initiative-Activity-Work-Performer 

43E  Initiative-Activity 

43E  Initiative-IT-Activity-Performer  (depicts  CDA) 

43E  Initiative-Supply-Agreement 

43E  Initiative-Supply-Resource-Pool 

43E-1  reports  Central  Design  Activities  (CDA)  by  system. 

Object  Area:  Entity: 

43E-1  Initiative  (indicates  system  designation) 

43E-1  Initiative  Supply-Assignment 

43E- 1  Initiative- Activity- Work-Resource-Pool 

43E- 1  Initiative-Activity- Work-Performer 

43E-1  Initiative- Activity 

43E-1  Initiative-IT- Activity-Performer  (depicts  CDA) 

43E-1  Initiative-Supply- Agreement 

43E- 1  Initiative-Supply-Resource-Pool 
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43F  identifies  development  and  modernization,  and  operational  and  maintenance  funds  spent  on  the 
financial  functions  within  any  system,  regardless  of  threshold. 

Object  Area:  Entity: 

43F  IT-Mechanism 

43F  IT-Organization-Mechanism 

43F  Initiative 

43F  Initiative  Supply-Assignment 

43F  Initiative-Activity-Work-Resource-Pool 

43F  Initiative-Activity-Milestone 

43F  Initiative-Activity-Work-Performer 

43F  Initiative-Activity 

43F  Initiative-IT-Activity-Performer 

43F  Initiative-Supply-Agreement 

43F  Initiative-Supply-Resource-Pool 

43F  Mechanism-Resource-Pool 

43F  Mechanism-Supply-Agreement 

43F  Mechanism-Supply-Resource-Pool 

43F  Mechanism-Supply-Requirement 
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Life  Cycle  Cost/Benefit  Reporting 

The  LCC/B  (life  cycle  cost/benefit)  cost  element  structure  provides  a  standard  vocabulary  for  the 
identification  and  classification  of  cost  elements  to  be  used  with  cost  analysis  which  will  facilitate  program 
review,  reduce  redundant  staff  actions,  and  provide  the  framework  for  the  development  of  specific 
program  cost  estimates. 


Object  Area: 

LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 
LCC/B  cost  element  structure 


Entity: 

IT-Mechanism 

IT-Organization-Mechanism 

Initiative  (indicates  system  designation) 

Initiative  Supply-Assignment 

Initiative-Activity-Work-Resource-Pool 

Initiative-Activity-Milestone 

Initiative-  Activity-W  ork-Performer 

Initiative-Activity 

Initiative-IT-Activity-Performer 

Initiative-Supply-Agreement 

Initiative-Supply-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Supply-Agreement 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Requirement 
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The  Preliminary  FEA  (Functional  Economic  Analysis)  is  the  principle  document  in  the  Evaluation 
Decision  Package.  It  is  used  to  conduct  an  initial  "rough  order  of  magnitude"  assessment  of  proposed 
alternatives  to  the  AS-IS  process,  data,  and  systems  baseline  based  on  readily  available  information.  All 
information  supporting  the  Preliminary  FEA  is  available  to  the  Final  FEA,  particularly  the  following: 

Object  Area:  Entity: 

Preliminary  FEA  Activity-Control-Driver 

Preliminary  FEA  Activity-Input 

Preliminary  FEA  Activity-Mechanism 

Preliminary  FEA  Activity-Model-Version 

Preliminary  FEA  Activity-Output 

Preliminary  FEA  Activity-Performance-Objective-Driver 

Preliminary  FEA  Activity-Performance-Objective 

Preliminary  FEA  Activity-Workload 

Preliminary  FEA  By-Product 

Preliminary  FEA  Discontinued  Activity 

Preliminary  FEA  Extemal-Improvement-Impact 

Preliminary  FEA  Fincncial-Resource-Pool-Driver 

Preliminary  FEA  Functional  Activity 

Preliminary  FEA  Functional  Area 

Preliminary  FEA  Functional-Alternative 

Preliminary  FEA  Functional-Altemative-Initiative 

Preliminary  FEA  Functional-Requirement 

Preliminary  FEA  Improvement-Opportunity-Impact 

Preliminary  FEA  Improvement-Opportunity 

Preliminary  FEA  Initiative 

Preliminary  FEA  Initiative-Activity 

Preliminary  FEA  Initiative-Activity-Link 

Preliminary  FEA  Introduced  Activity 

Preliminary  FEA  Mechanism-Resource-Pool 

Preliminary  FEA  Model-Activity 

Preliminary  FEA  Model-Activity-Transition-Link 

Preliminary  FEA  Non-Value-Added-Activity 

Preliminary  FEA  Organization-Mechanism 

Preliminary  FEA  Organization-Position 

Preliminary  FEA  Organizational-Unit 

Preliminary  FEA  Performance-Achievement 

Preliminary  FEA  Performance-Measure 

Preliminary  FEA  Performance-Objective 

Preliminary  FEA  Position-Mechanism 

Preliminary  FEA  Primary-Output 

Preliminary  FEA  Replacement  Activity 

Preliminary  FEA  Strategic-Goal 

Preliminary  FEA  Strategic-Performance-Objective 

Preliminary  FEA  Supporting-Performance-Objective 

Preliminary  FEA  Value-Added-Activity 
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The  Final  FEA  is  the  revision  to  the  Preliminary  FEA  that  is  included  in  the  Approval  Decision  Package. 
It  contains  amore  detailed  analysis  based  on  a  refinement  of  the  cost,  benefit,  and  schedule  data  that  were 
included  in  the  Preliminary  FEA. 


Object  Area: 

Entity: 

Final  FEA 

Activity- Workload 

Final  FEA 

Extemal-Improvement-Impact 

Final  FEA 

Functional  Activity 

Final  FEA 

Functional  Area 

Final  FEA 

Functional-Alternative 

Final  FEA 

Functional-Altemative-Initiative 

Final  FEA 

Functional-Requirement 

Final  FEA 

Funding-Source 

Final  FEA 

Improvement-Opportunity-Impact 

Final  FEA 

Improvement-Opportunity 

Final  FEA 

Initiative 

Final  FEA 

Initiative-Activity-Milestone 

Final  FEA 

Initiative-Activity-Work-Performer 

Final  FEA 

Initiative-IT  -Activity-Performer 

Final  FEA 

Performance-Objective 

Final  FEA 

Primary-Output 

Final  FEA 

Strategic-Goal 

Final  FEA 

Strategic-Performance-Objective 

Final  FEA 

Technical-Specification 

Final  FEA 

Technical-Supply-Requirement 
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The  Update  FEA  is  a  periodic  progress  report  on  the  Final  FEA’s  approved  alternative  through  which 
costs  and  performance  improvements  are  compared  with  those  projected.  The  Update  FEA  provides 
updated  decision  monitoring  and  oversight  information  for  use  by  functional  managers  in  conducting 
program  evaluation  at  key  decision  points. 


Object  Area: 

Entity: 

Update  FEA 

Activity-Model-Version 

Update  FEA 

Activity-Performance-Objective 

Update  FEA 

Activity-Workload 

Update  FEA 

Agreement 

Update  FEA 

Contractor-Supply-Source 

Update  FEA 

Discontinued  Activity 

Update  FEA 

DoD-Component-Supply-Source 

Update  FEA 

Extemal-Improvement-Impact 

Update  FEA 

Functional-Requirement 

Update  FEA 

IT-Mechanism 

Update  FEA 

IT-Organization-Mechanism 

Update  FEA 

Improvement-Opportunity-Impact 

Update  FEA 

Improvement-Opportunity 

Update  FEA 

Initiative 

Update  FEA 

Initiative  Supply-Assignment 

Update  FEA 

Initiative-Activity-Work-Resource-Pool 

Update  FEA 

Initiative-Activity 

Update  FEA 

Initiative-Activity-Link 

Update  FEA 

Initiative-Supply-Agreement 

Update  FEA 

Initiative-Supply-Resource-Pool 

Update  FEA 

Introduced  Activity 

Update  FEA 

Mechanism-Resource-Pool 

Update  FEA 

Mechanism-Supply-Agreement 

Update  FEA 

Mechanism-Supply-Resource-Pool 

Update  FEA 

Mechanism-Supply-Requirement 

Update  FEA 

Model-Activity 

Update  FEA 

Model-  Activity-T  ransition-Link 

Update  FEA 

Non-DoD-Govemment-Supply-Source 

Update  FEA 

Non-Value-Added-Activity 

Update  FEA 

Organization-Mechanism 

Update  FEA 

Performance-Achievement 

Update  FEA 

Performance-Objective 

Update  FEA 

Primary-Output 

Update  FEA 

Replacement  Activity 

Update  FEA 

Strategic-Goal 

Update  FEA 

Strategic-Performance-Objective 

Update  FEA 

Supplier 

Update  FEA 

Suppl  ier- Agreement 

Update  FEA 

Value-Added-Activity 
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4.6.2  Entities  and  the  Object  Areas  They  Address 

Entity: 

Object  Area: 

Activity-Control-Driver 

Preliminary  FEA 

Activity-Input 

Preliminary  FEA 

Activity-Mechanism 

Preliminary  FEA 

Activity-Model 

Activity-Model 

43A-1C1 

43A-2A 

Activity-Model-Version 

Activity-Model-Version 

Preliminary  FEA 
Update  FEA 

Activity-Output 

Preliminary  FEA 

Activity-Performance-Objective-Driver 

Preliminary  FEA 

Activity-Performance-Objective 

Activity-Performance-Objective 

Preliminary  FEA 
Update  FEA 

Activity-Workload 

Activity-Workload 

Activity-Workload 

Final  FEA 
Preliminary  FEA 
Update  FEA 

Agreement 

Agreement 

Agreement 

43B 

43D 

Update  FEA 

By-Product 

Preliminary  FEA 

Contractor-Supply-Source 

Contractor-Supply-Source 

Contractor-Supply-Source 

43B 

43D 

Update  FEA 

Discontinued  Activity 

Discontinued  Activity 

Discontinued  Activity 

43C 

Preliminary  FEA 
Update  FEA 

DoD-Component-Supply-Source 

DoD-Component-Supply-Source 

DoD-Component-Supply-Source 

43B 

43D 

Update  FEA 
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Entity: 

Object  Area: 

External-Improvement-Impact 

Extemal-Improvement-Impact 

External-Improvement-Impact 

Final  FEA 

Preliminary  FEA 

Update  FEA 

Financial-Resource-Pool-Driver 

Preliminary  FEA 

Functional  Activity 

Functional  Activity 

Functional  Activity 

Functional  Activity 

43A-1C1 

43A-2A 

Final  FEA 

Preliminary  FEA 

Functional  Area 

Functional  Area 

Functional  Area 

Functional  Area 

43  A- 1C  1 

43A-2A 

Final  FEA 

Preliminary  FEA 

Functional-Alternative 

Functional-Alternative 

Final  FEA 

Preliminary  FEA 

Functional-Altemative-Initiative 

Functional-Altemative-Initiative 

Final  FEA 

Preliminary  FEA 

Functional-Requirement 

Functional-Requirement 

Functional-Requirement 

Functional-Requirement 

43C 

Final  FEA 

Preliminary  FEA 

Update  FEA 

Funding-Source 

Final  FEA 

IT-Mechanism 

IT-Mechanism 

IT-Mechanism 

IT-Mechanism 

IT-Mechanism 

IT-Mechanism 

IT-Mechanism 

43A-2 

43A-2A 

43B 

43C 

43F 

LCC/B  cost  element  structure 
Update  FEA 

IT-Organization-Mechanism 

IT -Organization-Mechanism 

IT -Organization-Mechanism 
IT-Organization-Mechanism 

IT -Organization-Mechanism 
IT-Organization-Mechanism 

43A-2 

43A-2A 

43C 

43F 

LCC/B  cost  element  structure 
Update  FEA 
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Entity: 

Improvement-Opportunity-Impact 

Improvement-Opportunity-Impact 

Improvement-Opportunity-Impact 

Improvement-Opportunity-Impact 

Improvement-Opportunity 

Improvement-Opportunity 

Improvement-Opportunity 

Improvement-Opportunity 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative 

Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 
Initiative  Supply-Assignment 


Object  Area: 

43C 

Final  FEA 
Preliminary  FEA 
Update  FEA 

43C 

Final  FEA 
Preliminary  FEA 
Update  FEA 

43  A- 1 

43A-1A 

43A-1B 

43A-1C 

43A-1C1 

43B 

43C 

43E-1 

43F 

Final  FEA 

LCC/B  cost  element  structure 
Preliminary  FEA 
Update  FEA 

43  A- 1 

43A-1A 

43A-1B 

43A-1C 

43A-1C1 

43B 

43C 

43D 

43E 

43E-1 

43F 

LCC/B  cost  element  structure 
Update  FEA 
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Entity: 

Object  Area: 

Initiative- Activity-Work-Resource-Pool 

43  A- 1 

Initiative-Activity-Work-Resource-Pool 

43A-1A 

Initiative-Activity-Work-Resource-Pool 

43A-1B 

Initiative-Activity-Work-Resource-Pool 

43A-1C 

Initiative- Activity-Work-Resource-Pool 

43A-1C1 

Initiative-Activity-Work-Resource-Pool 

43C 

Initiative-Activity-Work-Resource-Pool 

43E 

Initiative- Activity-Work-Resource-Pool 

43E-1 

Initiative-Activity-Work-Resource-Pool 

43F 

Initiative-Activity-Work-Resource-Pool 

LCC/B  cost  element  structure 

Initiative-Activity-Work-Resource-Pool 

Update  FEA 

Initiative-Activity-Milestone 

43  A- 1 

Initiative-Activity-Milestone 

43A-1A 

Initiative-Activity-Milestone 

43A-1B 

Initiative-Activity-Milestone 

43A-1C 

Initiative-Activity-Milestone 

43A-1C1 

Initiative-Activity-Milestone 

43C 

Initiative-Activity-Milestone 

43F 

Initiative-Activity-Milestone 

Final  FEA 

Initiative-Activity-Milestone 

LCC/B  cost  element  structure 

Initiative-Activity-Work-Performer 

43A-1 

Initiative-Activity-Work-Performer 

43A-1A 

Initiative-Activity-Work-Performer 

43  A- IB 

Initiative-Activity-Work-Performer 

43  A- 1C 

Initiative-Activity-Work-Performer 

43A-1C1 

Initiative-Activity-Work-Performer 

43B 

Initiative-Activity-Work-Performer 

43C 

Initiative-Activity-Work-Performer 

43E 

Initiative-Activity-Work-Performer 

43E-1 

Initiative-Activity-Work-Performer 

43F 

Initiative-Activity-Work-Performer 

Final  FEA 

Initiative-Activity- Work-Performer 

LCC/B  cost  element  structure 

Initiative-Activity 

43  A- 1 

Initiative-Activity 

43A-1A 

Initiative-Activity 

43  A- IB 

Initiative-Activity 

43  A- 1C 

Initiative-Activity 

43A-1C1 

Initiative-Activity 

43C 

Initiative-Activity 

43D 

Initiative-Activity 

43E 

Initiative-Activity 

43E-1 

Initiative-Activity 

43F 
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Entity: 

Initiative- Activity 
Initiative-Activity 
Initiative-Activity 

Initiative-Activity-Link 

Initiative-Activity-Link 

Initiative-Activity-Link 

Initiative-IT-Activity-Perfonner 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Perfonner 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Perfonner 

Initiative-IT-Activity-Perfonner 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-IT-Activity-Performer 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Agreement 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 


Object  Area: 

LCC/B  cost  element  structure 
Preliminary  FEA 
Update  FEA 

43C 

Preliminary  FEA 
Update  FEA 

43  A- 1 

43A-1A 

43A-1B 

43  A- 1C 

43A-1C1 

43B 

43C 

43D 

43E 

43E-1 

43F 

Final  FEA 

LCC/B  cost  element  structure 

43  A- 1 

43A-1A 

43A-1B 

43A-1C 

43A-1C1 

43B 

43C 

43D 

43E 

43E-1 

43F 

LCC/B  cost  element  structure 
Update  FEA 

43  A- 1 

43A-1A 

43  A- IB 

43A-1C 

43A-1C1 

43B 

43C 

43D 

43E 
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Functional  Manager's  Perspective 


Entity: 

Object  Area: 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

Initiative-Supply-Resource-Pool 

43E-1 

43F 

LCC/B  cost  element  structure 
Update  FEA 

Introduced  Activity 

Introduced  Activity 

Introduced  Activity 

43C 

Preliminary  FEA 

Update  FEA 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

Mechanism-Resource-Pool 

43A-2 

43A-2A 

43C 

43F 

LCC/B  cost  element  structure 
Preliminary  FEA 

Update  FEA 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

Mechanism-Supply-Agreement 

43A-2 

43A-2A 

43B 

43C 

43D 

43F 

LCC/B  cost  element  structure 
Update  FEA 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

Mechanism-Supply-Resource-Pool 

43A-2 

43A-2A 

43B 

43C 

43D 

43F 

LCC/B  cost  element  structure 
Update  FEA 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

Mechanism-Supply-Requirement 

43A-2 

43A-2A 

43B 

43C 

43D 

43F 

LCC/B  cost  element  structure 
Update  FEA 
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Functional  Manager’s  Perspective 


Entity: 

Object  Area: 

Model-Activity 

Model-Activity 

Preliminary  FEA 
Update  FEA 

Model-Activity-Transition-Link 

Model-Activity-Transition-Link 

Preliminary  FEA 
Update  FEA 

Non-DoD-Govemment-Supply-Source 

Non-DoD-Govemment-Supply-Source 

Non-DoD-Govemment-Supply-Source 

43B 

43D 

Update  FEA 

Non-Value-Added-Activity 

Non-Value-Added-Activity 

Preliminary  FEA 
Update  FEA 

Organization-Mechanism 

Organization-Mechanism 

Preliminary  FEA 
Update  FEA 

Organization-Position 

Preliminary  FEA 

Organizational-Unit 

Preliminary  FEA 

Performance-Achievement 

Performance-Achievement 

Preliminary  FEA 
Update  FEA 

Performance-Measure 

Preliminary  FEA 

Performance-Objective 

Performance-Objective 

Performance-Objective 

Final  FEA 
Preliminary  FEA 
Update  FEA 

Position-Mechanism 

Preliminary  FEA 

Primary-Output 

Primary-Output 

Primary-Output 

Final  FEA 
Preliminary  FEA 
Update  FEA 

Replacement  Activity 

Replacement  Activity 

Replacement  Activity 

43C 

Preliminary  FEA 
Update  FEA 

Strategic-Goal 

Strategic-Goal 

Strategic-Goal 

Final  FEA 
Preliminary  FEA 
Update  FEA 
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Entity: 

Object  Area: 

Strategic-Performance-Objective 

Strategic-Performance-Objective 

Strategic-Performance-Objective 

Final  FEA 
Preliminary  FEA 
Update  FEA 

Supplier 

Supplier 

43D 

Update  FEA 

Supplier-Agreement 

Supplier-Agreement 

43D 

Update  FEA 

Supporting-Performance-Objective 

Preliminary  FEA 

Technical-Specification 

Technical-Specification 

43C 

Final  FEA 

Technical-Supply-Requirement 

Technical-Supply-Requirement 

43D 

Final  FEA 

Value-Added-Activity 

Value-Added- Activity 

Preliminary  FEA 
Update  FEA 
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Appendix  A  Acronyms  &  Abbreviations 
A.1  Acronyms 

ABC  Activity  Based  Costing 

AIS  Automated  Information  System 

AK  Alternate  Key 

C3I  Command,  Control,  Communications  &  Intelligence 

CAGE  Commercial  and  Government  Entity 

CIM  Corporate  Information  Management 

COTS  Commercial  Off-the-shelf  Software 

DDI  Director,  Defense  Information 

DFAS  Defense  Financial  &  Accounting  Service 

DISA  Defense  Information  Systems  Agency 

DMRD  Defense  Management  Review  Decision 

DoD  Department  of  Defense 

DODI  Department  of  Defense  Instruction 

ECAC  Electromagnetic  Compatibility  and  Analysis  Center 

FEA  Functional  Economic  Analysis 

FK  Foreign  Key 

FM  Financial  Management 

FPI  Functional  Process  Improvement 

FPIP  Functional  Process  Improvement  Program 

HQDA  Headquarters,  Department  of  the  Army 

HQ  USAF  Headquarters,  United  States  Air  Force 

ICAM  Integrated  Computer  Aided  Manufacturing 

ICOM  Input,  Control,  Output,  Mechanism 

IDA  Institute  for  Defense  Analysis 

IDEF  Integrated  Definition  Language 

IDEF-UG  IDEF  Users  Group 

IRM  Information  Resources  Management 

IS  Information  Systems 

IT  Information  Technology 

JLSC  Joint  Logistics  Systems  Command 

LMI  Logistics  Management  Institute 

MAISRC  Major  Automated  Information  System  Review  Council 

NCA  National  Command  Authority 
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Acronyms  &  Abbreviations 

OASD 

Office  of  the  Assistant  Secretary  of  Defense 

ODISC4 

Office  of  the  Director  of  Information  Systems,  Command,  Control,  Communications  &  1 

Computers 

OTI 

Office  of  Technical  Integration 

PA&E 

Program  Analysis  &  Evaluation 

PBD 

Program  Budget  Decision 

PE 

Program  Element 

P&L 

Production  &  Logistics 

POM 

Program  Objective  Memorandum 

PPBS 

Program  &  Planning  Budget  System 

SMEs 

Subject  Matter  Experts 

SRA 

Systems  Research  &  Applications 

STRAP 

Strategic  Requirements  Analysis  Planning 

UIC 

Unit  Identification  Code 

USACE 

U.S.  Army  Corps  of  Engineers 

USA  FM 

U.S.  Army  Financial  Management 

WBS 

Work  Breakdown  Structure 

A2  Abbreviations 

Appr 

Approved 

Acq 

Acquisition 

Act 

Activity 

ID 

Identifier 

Mgr 

Manager 

Org 

Organization 

Prog 

Program 

Reqmt 

Requirement 
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Appendix  B  FPI  Integrated  Data  Model 
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Appendix  C  FPI  Data  Model  Business  Rules 

Each  ACTIVITY  is  described  in  one  or  more  ACTIVITY-VERSION. 


Business  Rules 


Each  ACTIVITY-CONTROL  is  measured  as  zero,  one  or  more  ACTIVITY  -CONTROL-DRIVER. 

Each  ACTIVITY-DRIVER  may  be  a  COST-DRIVER  based  on  the  discriminator  DRIVER-FOCUS. 

Each  ACTIVITY-DRIVER  may  be  a  PERFORMANCE-DRIVER  based  on  the  discriminator 
DRIVER-FOCUS. 

Each  ACTIVITY-DRIVER  may  be  a  SCHEDULE-DRIVER  based  on  the  discriminator  DRIVER- 
FOCUS. 

Each  ACTIVITY-DRIVER  describes  one  or  more  ACTIVITY-CONTROL-DRIVER. 


Each  ACTIVITY-DRIVER  describes  zero,  one  or  more  ACTIVITY -PERFORMANCE-OB JECTTVE- 
DRTVER. 


Each  ACTIVITY-DRIVER  describes  one  or  more  FINANCIAL-RESOURCE-POOL-DRIVER. 


Each  ACTIVITY-DRIVER  generates  levels  of  effort  as  zero,  one  or  more  ACTIVITY-WORKLOAD. 

Each  ACTIVITY-ICOM  must  be  either  an  ACTIVITY-CONTROL,  ACTIVITY-INPUT,  ACTIVITY- 
MECHANISM,  or  an  ACTIVITY-OUTPUT  based  on  the  discriminator  ICOM-TYPE. 

Each  ACTIVITY-MECHANISM  may  be  an  IT-MECHANISM  based  on  die  discriminator 
MECHANISM-TYPE. 

Each  ACTIVITY-MECHANISM  may  be  an  ORGANIZATION-MECHANISM  based  on  the 
discriminator  MECHANISM-TYPE. 

Each  ACTIVITY-MECHANISM  may  be  an  POSITION-MECHANISM  based  on  the  discriminator 
MECHANISM-TYPE. 


Each  ACTIVITY-MECHANISM  is  funded  by  zero,  one  or  more  MECHANISM-RESOURCE-POOL. 

Each  ACTIVITY-MECHANISM  places  an  acquisition  demand  as  zero,  one  or  more 
MECHANISM-SUPPLY-REQUIREMENT. 

Each  ACTIVITY-MODEL  may  be  a  FUNCTIONAL-ACTIVITY  based  on  the  discriminator  MODEL- 
FOCUS. 

Each  ACTIVITY-MODEL  may  be  a  FUNCTIONAL-AREA  based  on  die  discriminator  MODEL- 
FOCUS. 

Each  ACTIVITY-MODEL  progresses  over  time  as  one  or  more  ACTIVITY-MODEL- VERSION. 
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Each  ACTIVITY-MODEL-VERSION  contains  zero,  one  or  more  MODEL-ACTIVITY. 


Each  ACTIVITY-MODEL-VERSION  contains  zero,  one  or  more  MODEL-ICOM. 

Each  ACTIVITY-MODEL-VERSION  depicts  the  To  Be  state  of  zero,one  or  more 
FUNCTIONAL-ALTERNATIVE. 

Each  ACTIVITY-MODEL-VERSION  describes  the  steps  in  zero,  one  or  more  INITIATIVE. 

Each  ACTIVITY-MODEL-VERSION  is  designed  to  meet  one  or  more 
PERFORMANCE-OBJECTIVE. 

Each  ACTIVITY-MODEL-VERSION  is  designed  to  meet  one  or  more  STRATEGIC-GOAL. 

Each  ACTIVITY-MODEL-VERSION  is  realized  as  zero,  one  or  more  INITIATIVE. 

Each  ACTIVITY-OUTPUT  may  be  a  BY-PRODUCT  based  on  the  discriminator  OUTPUT-TYPE. 

Each  ACTIVITY-OUTPUT  may  be  a  PRIMARY-OUTPUT  based  on  the  discriminator  OUTPUT- 
TYPE. 

Each  ACTIVITY-PERFORMANCE-OBJECTIVE  is  affected  by  zero,  one  or  more 
ACTIVITY-PERFORMANCE-OBJECTIVE-DRIVER. 

Each  ACTIVITY-VERSION  defines  zero,  one  or  more  INITIATIVE-ACTIVITY. 

Each  ACTIVITY-VERSION  defines  zero,  one  or  more  MODEL-ACTIVITY. 

Each  AGREEMENT  specifies  one  or  more  SUPPLIER-AGREEMENT. 

Each  COMPONENT  arranges  work  and  missions  through  one  or  more  ORGANIZATIONAL-UNIT. 

Each  COMPONENT  manages  resources  through  zero,  one  or  more  PROGRAM-ELEMENT. 

Each  COMPONENT  requests  funds  as  zero,  one  or  more  FUNDING-SOURCE. 

Each  COMPONENT-ACTIVITY  immediately  precedes  zero,  one  or  more  COMPONENT-ACTIVITY. 

Each  DEFENSE-PROGRAM  comprises  one  or  more  PROGRAM-ELEMENT. 

Each  DEFENSE-PROGRAM  is  divided  into  management  focus  areas  as  zero,  one  or  more 
DEFENSE-SUB-PROGRAM. 

Each  DEFENSE-PROGRAM  is  funded  by  zero,  one  or  more 
DEFENSE-PROGRAM-APPROPRIATION. 

Each  DEFENSE-PROGRAM-APPROPRIATION  funds  one  or  more 
ORGANIZATION-APPROPRIATION. 
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Each  DEFENSE-SUB-PROGRAM  comprises  one  or  more  PROGRAM-ELEMENT. 

Each  DRIVER  describes  zero,  one  or  more  ACTIVITY-DRIVER. 

Each  FINANCIAL-RESOURCE-POOL  funds  zero,  one  or  more 
INITIATIVE-ACTIVITY -WORK-RESOURCE-POOL. 

Each  FINANCIAL-RESOURCE-POOL  funds  zero,  one  or  more 
INITIATIVE-SUPPLY-RESOURCE-POOL. 

Each  FINANCIAL-RESOURCE-POOL  funds  zero,  one  or  more  MECHANISM-RESOURCE-POOL. 

Each  FINANCIAL-RESOURCE-POOL  is  caused  by  zero,  one  or  more 
FINANCIAL-RESOURCE-POOL-DRTVER. 

Each  FINANCIAL-RESOURCE-POOL  funds  zero,  one  or  more 
MECHANISM-SUPPLY-RESOURCE-POOL. 

Each  FUNCTIONAL  AREA  comprises  one  or  more  FUNCTIONAL  ACTIVITY. 

Each  FUNCTIONAL-ALTERNATIVE  is  changed  through  zero,  one  or  more 
FUNCTIONAL-ALTERNATIVE-INrriATIVE. 

Each  FUNCTIONAL-REQUIREMENT  is  converted  into  zero,  one  or  more 
TECHNICAL-SPECIFICATION. 

Each  FUNDING-SOURCE  may  be  an  APPROPRIATION-FUND-SOURCE  based  on  the  discriminator 
FUNDING-SOURCE-TYPE. 

Each  FUNDING-SOURCE  may  be  a  REVOLVING-FUND-SOURCE  based  on  the  discriminator 
FUNDING-SOURCE-TYPE. 

Each  FUNDING-SOURCE  funds  one  or  more  DEFENSE-PROGRAM-APPROPRIATION. 

Each  ICOM  is  described  in  zero,  one  or  more  ICOM-VERSION. 

Each  ICOM-VERSION  defines  zero,  one  or  more  MODEL-ICOM. 

Each  IMPROVEMENT-OPPORTUNITY  is  supported  by  one  or  more 
FUNCTIONAL-REQUIREMENT. 

Each  IMPROVEMENT-OPPORTUNITY  results  as  one  or  more 
IMPROVEMENT-OPPORTUNITY-IMPACT. 

Each  IMPROVEMENT-OPPORTUNITY-IMPACT  may  be  an  EXTERNAL-IMPROVEMENT- 
IMPACT  based  on  the  discriminator  IMPROVEMENT-IMPACT-FOCUS. 

Each  INITIATIVE  accomplishes  zero,  one  or  more  TECHNICAL-SPECIFICATION. 
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Each  INITIATIVE  is  achieved  through  one  or  more  INITIATIVE-ACTIVITY. 

Each  INITIATIVE  is  selected  as  zero.one  or  more  FUNCTIONAL-ALTERNATIVE-INITIATIVE. 


Each  INITIATIVE-ACTIVITY  may  be  an  INITIATIVE- ACTIVITY-MILESTONE  based  on  the 
discriminator  INITIATIVE-ACTIVITY-MILESTONE-INDICATOR. 


Each  INITIATIVE-ACTIVITY  is  accomplished  by  zero,  one  or  more 
INITIATIVE-ACTIVITY -WORK-PERF  ORMER. 


Each  INITIATIVE-ACTIVITY  precedes  zero, one  or  more  INITIATIVE-ACTIVITY-LINK. 
Each  INITIATIVE-ACTIVITY  succeeds  zero,  one  or  more  INITIATIVE-ACTIVITY-LINK. 


Each  INITIATIVE-ACTIVITY  triggers  the  realization  of  zero,  one  or  more  DISCONTINUED 
ACTIVITY. 

Each  INITIATIVE-ACTIVITY  triggers  the  realization  of  zero,  one  or  more  INTRODUCED 
ACTIVITY. 

Each  INITIATIVE-ACTIVITY  triggers  the  realization  of  zero,  one  or  more 
MODEL-ACTIVITY  -TRANSITION-LINK. 

Each  INITIATrVE-ACTrVITY-WORK-PERFORMER  may  be  an  INITIATIVE-IT-ACTIVITY- 
PERFORMER  based  on  the  discriminator  INITIATIVE-IT-FOCUS. 

Each  INITIATIVE-ACTIVITY-WORK-PERFORMER  causes  one  or  more 
INITIATIVE-ACTIVITY -WORK-RESOURCE-POOL. 

Each  INITIATIVE-ACTIVITY-WORK-PERFORMER  gets  zero,  one  or  more 
INITIATIVE-SUPPLY-AGREEMENT. 

Each  INITIATIVE-SUPPLY-AGREEMENT  causes  zero,  one  or  more 
INITIATIVE-SUPPLY -RESOURCE-POOL. 

Each  INITIATIVE-SUPPLY -AGREEMENT  satisfies  demand  through  zero,  one  or  more  INITIATIVE- 
SUPPLY-ASSIGNMENT. 

Each  LEAF-ACTIVITY  decomposition  is  referenced  by  zero,  one  or  more 
ACTIVITY-DECOMPOSmON-REFERENCE. 

Each  MECHANISM-SUPPLY-AGREEMENT  is  funded  by  zero,  one  or  more 
MECHANISM-SUPPLY-RESOURCE-POOL. 

Each  MECHANISM-SUPPLY-REQUIREMENT  is  satisfied  through  zero,  one  or  more 
MECHANISM-SUPPLY-AGREEMENT. 
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Business  Rules 


Each  MODEL-ACTIVITY  must  be  either  a  COMPONENT-ACTIVITY  or  a  ROOT-ACTIVITY  based 
on  the  discriminator  IS-ROOT-ACTIVITY. 

Each  MODEL-ACTIVITY  must  be  either  a  DISCONTINUED-ACTIVITY,  INTRODUCED- 
ACTIVITY,  or  a  REPLACEMENT-ACTIVITY  based  on  the  discriminator  EFFECTIVITY-FOCUS. 

Each  MODEL-ACTIVITY  may  be  a  NON-VALUE-ADDED-ACTIVITY  based  on  the  discriminator 
VALUE-ADDED-INDICATOR. 

Each  MODEL-ACTIVITY  must  be  either  a  PARENT-ACTIVITY  or  a  LEAF-ACTIVITY. 

Each  MODEL-ACTIVITY  may  be  a  VALUE-ADDED-ACTIVITY  based  on  the  discriminator 
VALUE-ADDED-INDICATOR. 

Each  MODEL-ACTIVITY  accomplishes  zero,  one  or  more 
ACTIVITY-PERFORMANCE-OBJECTIVE. 

Each  MODEL-ACTIVITY  has  causal  factors  identified  as  zero,  one  or  more  ACTIVITY-DRIVER. 

Each  MODEL-ACTIVITY  involves  zero,  one  or  more  ACTIVITY-ICOM. 

Each  MODEL-ICOM  appears  as  zero.one  or  more  ACTIVITY-ICOM. 

Each  MODEL-ICOM  appears  as  zero  ,one  or  more  COMPONENT-ICOM. 

Each  MODEL-ICOM  is  bundle  of  zero,one  or  more  COMPONENT-ICOM. 

Each  ORGANIZATION-APPROPRIATION  comprises  zero,one  or  more 
ORGANIZATION-PROGRAM-ELEMENT. 

Each  ORGANIZATION-MECHANISM  may  be  an  IT-ORGANIZATION-MECHANISM  based  on  the 
discriminator  ORGANISM-MECHANISM-FOCUS. 

Each  ORGANIZATION-PROGRAM-ELEMENT  describes  zero,  one  or  more 
FINANCIAL-RESOURCE-POOL. 

Each  ORGANIZATIONAL-UNIT  acts  as  zero,  one  or  more 
INITIATIVE-ACnVITY-WORK-PERFORMER. 

Each  ORGANIZATIONAL-UNIT  comprises  zero,  one  or  more  ORGANIZATIONAL-UNIT. 

Each  ORGANIZATIONAL-UNIT  converts  zero,  one  or  more  FUNCTIONAL-REQUIREMENT. 

Each  ORGANIZATIONAL-UNIT  is  accountable  for  zero, one  or  more  INITIATIVE-ACTIVITY. 

Each  ORGANIZATIONAL-UNIT  is  funded  by  zero,  one  or  more 
ORGANIZATION-APPROPRIATION. 
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Business  Rules 


Each  ORGANIZATIONAL-UNIT  is  represented  as  zero,  one  or  more 
ORGANIZATION-MECHANISM. 

Each  ORGANIZATIONAL-UNIT  needs  zero, one  or  more  ORGANIZATION-POSITION. 

Each  ORGANIZATIONAL-UNIT  serves  as  zero, one  or  more 
DOD-COMPONENT-SUPPLY-SOURCE. 

Each  PARENT-ACTIVITY  is  decomposed  into  one  or  more  COMPONENT-ACTIVITY. 

Each  PARENT-ACTIVITY  is  referenced  in  zero,  one  or  more 
ACTIVITY-DECOMPOSITION-REFERENCE. 

Each  PERFORMANCE-MEASURE  describes  zero,  one  or  more  PERFORMANCE-OBJECTIVE. 

Each  PERFORMANCE-OBJECTIVE  must  be  either  a  STRATEGIC-PERFORMANCE-OBJECTIVE 
or  a  SUPPORTING-PERFORMANCE-OBJECTIVE  based  on  the  discriminator  PERFORMANCE- 
OBJECTIVE-CLASS. 

Each  PERFORMANCE-OBJECTIVE  defines  zero,  one  or  more 
ACTIVITY-PERFORMANCE-OBJECTIVE. 

Each  PERFORMANCE-OBJECTIVE  is  measured  as  zero,  one  or  more 
PERFORMANCE-ACHIEVEMENT. 

Each  PERFORMANCE-OBJECTIVE  is  the  management  focus  of  zero,  one  or  more 
IMPROVEMENT-OPPORTUNITY. 

Each  POSITION  describes  zero,  one  or  more  ORGANIZATION-POSITION. 

Each  POSITION  is  represented  as  zero,one  or  more  POSITION-MECHANISM. 

Each  PRIMARY-OUTPUT  may  be  a  PRODUCT-OUTPUT  based  on  the  discriminator  PRIMARY- 
OUTPUT-TYPE. 

Each  PRIMARY-OUTPUT  may  be  a  SERVICE-OUTPUT  based  on  the  discriminator  PRIMARY- 
OUTPUT-TYPE. 

Each  PROGRAM-ELEMENT  describes  zero,one  or  more  ORGANIZATION-PROGRAM-ELEMENT. 

Each  REPLACEMENT  ACTIVITY  precedes  zero,  one  or  more 
MODEL-ACTIVITY-TRANSITION-LINK. 

Each  REPLACEMENT  ACTIVITY  succeeds  zero,  one  or  more 
MODEL-ACTIVITY-TRANSITION-LINK. 

Each  STRATEGIC-GOAL  specifies  accomplishment  as  zero,  one  or  more 
STRATEGIC-PERFORMANCE-OBJECTIVE. 
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Business  Rules 


Each  STRATEGIC-PERFORMANCE-OBJECTIVE  comprises  zero,  one  or  more 
SUPPORTING-PERFORMANCE-OBJECTIVE. 

Each  SUPPLIER  may  be  a  CONTRACTOR-SUPPLY-SOURCE  based  on  the  discriminator 
SUPPLIER-TYPE. 

Each  SUPPLIER  may  be  a  DOD-COMPONENT-SUPPLY-SOURCE  based  on  die  discriminator 
SUPPLIER-TYPE. 

Each  SUPPLIER  may  be  a  NON-DOD-GOVERNMENT-SUPPLY-SOURCE  based  on  the 
discriminator  SUPPLIER-TYPE. 

Each  SUPPLIER  provides  goods  or  services  in  zero,  one  or  more  SUPPLIER-AGREEMENT. 

Each  SUPPLIER-AGREEMENT  describes  zero,  one  or  more  INITIATIVE-SUPPLY-AGREEMENT. 

Each  SUPPLIER-AGREEMENT  satisfies  demand  through  zero,  one  or  more 
MECHANISM-SUPPLY-AGREEMENT. 

Each  TECHNICAL-SPECIFICATION  identifies  zero,  one  or  more 
TECHNICAL-SUPPLY-REQUIREMENT. 

Each  TECHNICAL-SUPPLY-REQUIREMENT  satisfies  demand  through  zero,  one  or  more 
INITIATIVE-SUPPLY-ASSIGNMENT 
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Appendix  D  Entity  Definitions 

ACTIVITY:  A  function,  process,  task,  action,  etc.,  that  requires  some  amount  of  time  to  produce  one  or 
more  discernible  results.  (Source:  IDEF-UG  Data  Model) 

ACTIVITY -CONTROL:  Information  that  triggers  or  constrains  an  ACTIVITY.  Controls  regulate  the 
transformation  of  inputs  into  outputs.  (Source:  ABC  Data  Model) 

ACTIVITY -CONTROL-DRIVER:  A  factor  that  has  a  direct  influence  on  ACTIVITY-CONTROLs. 

ACTIVITY -DECOMPOSITION-REFERENCE:  The  identification  of  a  PARENT-ACTIVITY  that  contains 
the  decomposition  of  a  LEAF-ACTIVITY.  The  PARENT-ACTIVITY  must  be  from  a  separate 
ACTIVITY-MODEL-VERSION  than  the  LEAF-ACTIVITY.  (Source:  IDEF-UG  Data  Model) 

ACTIVITY -DRIVER:  A  factor  that  influences  a  trigger  or  constraint  on  an  ACTIVITY. 

ACTIVITY -ICOM:  An  input  to,  an  output  from,  a  control  on,  or  a  mechanism  for  a  MODEL-ACTIVITY. 

ACTIVITY -INPUT:  Information  or  material  used  to  produce  the  output  of  an  activity. 

ACTIVITY -MECHANISM:  Usually  people,  machines,  or  information  systems  that  provide  energy  to, 
or  perform,  the  ACTIVITY.  Mechanisms  may  act  as  surrogates  for  consumed  resources.  (Source:  ABC 
Data  Model) 

ACTIVITY -MODEL:  A  graphic  and  textual  description  of  Activities  and  their  ICOMs  that  is  developed 
using  the  IDEFO  modeling  technique.  (Source:  IDEF-UG  Data  Model) 

ACTIVITY-MODEL-VERSION:  An  ACTIVITY-MODEL  may  change  over  time.  The  ACTIVITY- 
MODEL-VERSION  identifies  the  transitions. 

ACTIVITY -OUTPUT:  Information  or  material  produced  by  or  resulting  from  an  ACTIVITY. 

ACTIVITY -PERFORMANCE-OBJECTIVE:  Identifies  a  unique  occurrence  of  a  specific  intended  target 
as  the  result  of  accomplishing  an  activity. 

ACTIVITY-PERFORMANCE-OBJECTIVE-DRIVER:  The  linkage  of  a  specific  activity's 

PERFORMANCE-OBJECTIVE  to  a  factor  that  either  causes  it  or  directly  affects  its  attainment. 

ACTIVITY -VERSION:  The  properties  of  an  ACTIVITY  may  change  over  time.  The  version  identifies 
the  properties  at  a  point  in  time.  (Source:  IDEF-UG  Data  Model) 

ACTIVITY -WORKLOAD:  The  time-phased,  expected  overall  output  of  an  activity  for  a  specific  fiscal 
year. 

AGREEMENT:  A  contract,  arrangement  or  understanding  between  the  DoD  (or  any  of  its  Services  and 
Agencies)  and  another  party  for  the  provision  of  a  service  or  product. 
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APPROPRIATION-FUNDSOURCE:  Authorization  by  an  Act  of  Congress  to  incur  obligations  for 
specific  purposes  and  to  make  disbursements  for  them  from  the  U.S.  Treasury.  (Source:  Army  Financial 
Management  Data  Model) 

BY-PRODUCT:  An  expected,  secondary  output  that  is  generated  in  the  process  of  making,  or  enabling, 
the  activity’s  primary  output.  A  category  entity  of  ACTIVITY-OUTPUT. 

COMPONENT:  A  constituent  of  the  Department  of  Defense.  Can  be  any  of  the  Services  or  Agencies 
within  DoD. 

COMPONENT-ACTIVITY:  A  MODEL-ACTIVITY  that  is  part  of  the  decomposition  of  another 
MODEL-ACTIVITY.  (Source:  IDEF-UG  Data  Model) 

COMPONENT-PRIOR-ACTIVITY:  Depicts  the  sequential  order  of  decomposed  activities. 

COMPONENT-ICOM:  Identifies  one  MODEL-ICOM  (the  component)  that  appears  as  one  that  splits 
from,  or  merges  into,  another  MODEL-ICOM  (the  bundled  ICOM)  within  an  ACTIV1TY-MODEL- 
VERSION.  (Source:  IDEF-UG  Data  Model) 

CONTRACTOR-SUPPLY -SOURCE:  A  person  or  organization  who  agrees  to  furnish  materials  or 
perform  services  at  a  mutually  agreed  upon  price  as  defmed  in  a  contract.  (Source:  Army  FM  Data 
Model) 

COST-DRIVER:  A  factor  that  causes  cost  to  be  incurred  during  or  for  the  performance  an  activity. 

DEFENSE-PROGRAM:  An  aggregation  of  program  elements  that  reflect  a  force  mission  or  a  support 
mission  of  DoD.  (Source:  J.  Romito's  "PPBS  Information"  handout) 

DEFENSE-PROGRAM-APPROPRIATION:  A  specific  instance  of  APPROPRIATION  for  a  specific 
instance  of  DEFENSE-PROGRAM. 

DEFENSE-SUB-PROGRAM:  A  subdivision  of  a  Major  Force  Program. 

DISCONTINUED-ACTIVITY :  An  activity  that  has  been  terminated,  and  no  longer  appears  on  succeeding 
versions  of  an  activity  model,  e.g.,  a  non-value  added  activity. 

DOD-COMPONENTSUPPLY SOURCE:  Any  Service  or  Agency  within  the  Department  of  Defense 
providing  a  product  or  service  for  a  particular  task. 

DRIVER:  A  factor  that  has  a  direct  influence  on  activities  and  processes.  Within  a  business  process, 
drivers  are  inherited  by  all  other  downstream  activities. 

EXTERNAL-IMPROVEMENT-IMPACT:  The  expected  effect  or  result  (of  the  implementation  of  an 
improvement  opportunity)  on  a  DoD  Service  or  Agency  outside  the  scope  of  the  modeled  activities. 

FINANCIAL-RESOURCE-POOL:  An  apportionment  of  funds  that  relates  how  funds  are  spent  in  regard 
to  outcomes. 
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FINANCIAL-RESOURCE-POOL-DRIVER:  A  specific  DRIVER  that  affects  a  specific  FINANCIAL- 
RESOURCE-POOL. 

FUNCTIONAL-ACTIVITY:  Mutually  exclusive,  high-level  descriptions  of  what  DoD  does.  Each 
FUNCTIONAL-AREA  has  a  set  of  functional  activities.e.g.,  Medical  Logistics,  Medical  Defense  Research. 

FUNCTIONAL-ALTERNA  TIVE:  A  clearly  different  way  of  doing  business  from  the  current  way,  where 
present  and  future  workloads  are  performed  using  improved  processes,  including  die  affect  of  approved 
changes. 

FUNCTIONAL-ALTERNATIVE-INITIATIVE:  The  relationship  of  a  specific  initiative  to  a  functional 
alternative.  The  initiative  can  be  included  in  more  than  one  alternative,  and  may  carry  on  over  a  number 
of  iterations  of  business  process  improvement. 

FUNCTIONAL-AREA:  Encompasses  the  scope  of  the  functions  for  which  the  OSD  Principle  Staff 
Assistant  or  JCS  Chairman  has  responsibility,  authority,  and  accountability,  e.g..  Health.  (8020. 1-M) 

FUNCTIONAL-REQUIREMENT:  The  description  of  a  new  or  improved  work  feature  or  capability. 

FUNDING-SOURCE:  Authorization,  either  direcdy  from  Congress  in  an  appropriation  or  from  a 
customer  through  a  revolving  fund,  to  apply  financial  resources  to  the  accomplishment  of  specified 
purposes. 

ICOM:  A  type  or  class  of  things  (data,  things,  people,  etc.)  that  are  involved  with  activities  in  one  or 
more  of  the  following  roles: 

•  Inputs:  Things  which  are  consumed  or  transformed  by  Activities. 

•  Controls:  Things  that  govern,  constrain,  or  trigger  Activities. 

•  Outputs:  Things  that  are  produced  by  Activities. 

•  Mechanisms:  Things  that  perform,  energize  or  facilitate  Activities. 

ICOM-VERSION:  A  collection  of  information  about  an  ICOM  at  a  point  in  time.  The  information  about 
an  ICOM  may  change  over  time,  so  it  may  have  more  than  one  ICOM-VERSION.  (Source:  IDEF-UG 
Data  Model) 

IMPROVEMENT-OPPORTUNITY:  Is  an  actionable,  potential  change.  (Source:  FEA  Data  Model) 

IMPROVEMENT-OPPORTUNITY -IMPACT:  The  expected  effect  or  results  of  the  implementation  of 
an  improvement  opportunity,  e.g.,  a  potential  benefit  or  resource  consumption. 

INITIA  TIVE:  Controls  the  work  needed  to  accomplish  a  set  of  one-time  deliverables  that  implement 
improvements  in  a  baseline.  (Source:  FEA  Data  Model) 

INITIA  TIVE  A  CTIVITY.  A  function,  process,  task,  action,  etc.,  of  an  initiative  that  requires  some 
amount  of  time  to  produce  one  or  more  discernible  results. 

INITIA  TIVE-A  CTIVITY -LINK :  The  specific  links  between  INITIATIVE-ACTIVITY  node  pairs  which, 
as  a  set,  reflect  a  network  of  steps  towards  accomplishing  an  initiative. 
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INITIATIVE-ACTIVITY -MILESTONE:  A  defined  level  of  completion  and  acceptance  for  an 

inhiative-activity. 

INITIATIVE-ACTIVITY-WORK-PERFORMER:  The  individual  or  organization  responsible  for 

accomplishing  an  INITIATIVE-ACTIVITY. 

INITIATIVE-ACTIVITY  -WORK-RESOURCE-POOL:  An  apportionment  that  funds  work  on  a  specific 
INITIATIVE-ACTIVITY. 

INITIA  TIVE-IT-ACTIVITY-PER FORMER:  The  individual  or  organization  responsible  for  accomplishing 
an  IT-related  INITIATIVE-ACTIVITY. 

INITIA  TIVE-SUPPLY-AGREEMENT:  Identifies  the  relationship  between  internal  and  external  suppliers 
for  an  INITIATIVE. 

INITIATIVE-SUPPLY-ASSIGNMENT:  A  contract,  arrangement  or  understanding  between  the  DoD  (or 
any  of  its  Services  and  Agencies)  and  a  specific  SUPPLIER  for  the  provision  of  a  service  or  product  to 
meet  the  requirements  of  an  INITIATIVE-ACTIVITY. 

INITIATIVE-SUPPLY-RESOURCE-POOL:  An  apportionment  of  funds  for  a  particular  INITLATIVE- 
SUPPLY-AGREEMENT  providing  goods  or  services  to  an  INITIATIVE. 

INTRODUCED-ACTIVITY:  An  activity  that  first  appears  on  a  new  activity  model  version.  Typically, 
these  are  the  result  of  process  improvement  or  business  re-engineering  efforts. 

IT-MECHA NISM:  An  Information  Technology  resource  (computer-based  system  or  process)  that 
facilitates  the  accomplishment  of  an  activity. 

TT-ORGANIZA  TION-MECHANJSM:  Represents  people  involved  whose  primary  purpose  is  to  supply 
or  support  Information  Technology,  that  is,  the  person  is  there  because  the  computer  is  there. 

LEAF-ACTIVITY:  A  MODEL-ACTIVITY  that  is  not  decomposed  into  other  MODEL-ACTIVITIES. 
Each  of  these  is  at  the  end  of  a  branch  in  the  node  tree.  (Source:  IDEF-UG  Data  Model) 

MECHANISM-RESOURCE-POOL:  An  apportionment  of  funds  for  a  particular  MECHANISM-SUPPLY- 
AGREEMENT  providing  goods  or  services  identified  through  a  mechanism. 

MECHANISM-SUPPLY -A  GREEMENT:  A  contract,  arrangement  or  understanding  between  die  DoD  (or 
any  of  its  Services  and  Agencies)  and  a  specific  SUPPLIER  for  the  provision  of  a  service  or  product  to 
meet  a  MECHANISM-SUPPLY-REQUIREMENT. 

MECHANISM-SUPPLY-REQUIREMENT:  A  specification  that  has  been  converted  into  a  specific 
amount  of  a  discrete  product  or  service,  typically  at  a  level  of  detail  recognized  by  suppliers. 

MECHANISM-SUPPLY-RESOURCE-POOL:  An  apportionment  of  funds  for  a  particular  supply  source 
to  an  ACTIVITY. 
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MECHANISM-SUPPLY -SOURCE:  An  organization  that  provides  goods  or  services  required  to  perform 
work  on  an  ACTIVITY. 

MODEL-ACTIVITY :  An  ACTIVITY-VERSION  that  is  included  in  an  ACTIVITY-MODEL-VERSION. 
(Source:  IDEF-UG  Data  Model) 

MODEL-ACTIVITY -TRANSITION-LINK:  Indicates  die  transformation  of  one  version's  activity  to 
another  version's  activity,  either  through  combining  activities,  splitting  an  activity,  or  improving  die  same 
activity. 

MODEL-ICOM:  An  ICOM-VERSION  that  is  included  in  an  ACTIVITY-MODEL-VERSION.  (Source: 
IDEF-UG  Data  Model) 

NON-DOD-GOVERNMENTSUPPLYSOURCE:  A  government  department,  service,  or  agency  outside 
of  the  Department  of  Defense  providing  a  product  or  service  for  a  particular  task. 

NON-VALUE-ADDED-ACTIVITY :  An  activity  creates  delay,  excess,  or  variation  in  a  process.  (Source: 
FEA  Guidebook) 

ORGANIZATION-APPROPRIATION.  A  disbursement  of  funds  fiom  a  DEFENSE-PROGRAM- 
APPROPRIATION  to  a  particular  ORGANIZATIONAL-UNIT. 

ORGANIZATION-MECHANISM :  A  specific,  named  organization  that  provides  the  people  and  other 
resources  necessary  to  accomplish  the  activity. 

ORGANIZATION-POSITION:  A  specific  POSITION  that  operates  within  an  ORGANIZATIONAL- 
UNIT. 

ORGANIZATION-PROGRAM-ELEMENT:  An  organization  appropriation  broken  out  by  program 
element. 

ORGANIZATIONAL-UNIT:  One  of  the  divisions  or  directorates  that  comprise  a  COMPONENT.  An 
ORGANIZATIONAL-UNIT  may  be  the  parent  organization  (chain  of  command)  for  other 
ORGANIZATIONAL-UNITs. 

ORGANIZATIONAL-UNTTSTRUCTURE:  Depicts  the  hierarchical  composition  of  divisions  or 
directorates. 

PARENT-ACTIVITY:  A  MODEL-ACTIVITY  that  is  decomposed  into  other  MODEL-ACTIVITIES  (the 
components).  (Source:  IDEF-UG  Data  Model) 

PERFORMANCE-ACHIEVEMENT:  The  time-phased,  expected  and  realized  accomplishment  of  work 
in  a  given  fiscal  year. 

PERFORMANCE-DRIVER:  A  factor  that  has  a  direct  influence  on  die  performance  of  subsequent 
activities  and  processes. 
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PERFORMANCE-MEASURE :  A  factor  used  to  gauge  the  speed  or  responsiveness,  quality,  or  cost  of 
a  process,  input,  or  output.  (Source:  FEA  Guidebook) 

PERFORMANCE-OBJECTIVE-.  Quantifies  an  intended  or  targeted  output  which  is  factored  by  a 
performance  measure.  (Source:  FEA  Data  Model) 

POSITION :  A  set  of  skills  and  knowledge  needed  to  perform  an  activity  or  task;  a  job  role  (e.g.,  "Cost 
Analyst"). 

POSITION-MECHANISM:  A  specific  job  role  that  accomplishes  an  activity. 

PRIMARY -OUTPUT:  That  single,  measurable  result  of  an  ACTIVITY  by  which  the  cost  of  an 
ACTIVITY  is  accumulated. 

PRODUCT:  A  type  of  PRIMARY-OUTPUT  that  typically  produces  tangible  item. 

PROGRAM-ELEMENT:  Aggregation  of  organizational  entities  and  resources  related  to  the  Defense 
Program  which  is  a  breakdown  of  the  mqjor  program/sub-program.  (Source:  Army  Financial 
Management  Data  Model) 

REPLACEMENT-ACTIVITY:  An  activity  that  either  will  be  changed  or  is  the  result  of  a  change  from 
one  version  of  an  activity  model  to  another. 

REVOLVING-FUND-SOURCE:  Authorization  by  a  customer  through  a  revolving  fund  (primarily  the 
Defense  Business  Operating  Fund)  to  apply  financial  resources  for  specified  purposes.  This  category  of 
FUNDING-SOURCE  is  applied  to  the  revolving  fund  corpus,  from  which  disbursements  are  made. 

ROOT-ACTIVITY:  A  MODEL-ACTIVITY  that  is  not  part  of  the  decomposition  of  another  MODEL- 
ACTIVITY.  Each  ACTIVITY-MODEL  has  only  one  ROOT-ACTIVITY,  which  is  at  the  top  of  the  node 
tree.  (Source:  IDEF-UG  Data  Model) 

SCHEDULE-DRIVER:  A  factor  that  has  a  direct  influence  on  the  schedule  of  subsequent  activities  and 
processes. 

SERVICE:  A  type  of  PRIMARY-OUTPUT  where  the  supplier  performs  some  action  for  a  customer  that 
either  provides  a  level  of  effort  or  access  to  an  established  infrastructure. 

STRATEGIC-GOAL:  The  desired  high  level  outcome  that  drives  overall  policy  guidance. 

STRATEGIC-PERFORMANCE-OBJECTIVE:  A  type  of  PERFORMANCE-OBJECTIVE  that  directly 
relates  to  a  STRATEGIC-GOAL. 

SUPPLIER:  An  organization  that  provides  goods  or  services  required  by  an  to  perform  work  for  the  DoD 
and  any  of  its  Services  or  Agencies. 

SUPPLIER-AGREEMENT:  A  specific  contract,  arrangement  or  understanding  between  the  DoD  (or  any 
of  its  Services  and  Agencies)  and  a  specific  SUPPLIER  for  the  provision  of  a  service  or  product 
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S  UPPOR  TING-PER  FORMA  NCE-OBJECTIVE:  A  type  of  PERFORMANCE-OBJECTIVE  that  m  easurcs 
some  action  of  the  business,  but  is  not  directly  linked  to  a  STRATEGIC-GOAL. 

TECHNICAL-SPECIFICA  TION :  The  interpretation/conversion  of  a  functional  requirement  to  the  specific 
level  of  detail  needed  for  acquisition  or  implementation. 

TECHNICAL-SUPPLY -REQUIREMENT-.  A  specification  that  has  been  converted  into  a  specific  amount 
of  a  discrete  product  or  service.  Typically,  at  a  level  of  detail  recognized  by  outside  suppliers. 

VA L  UE- ADDED- A  CTIVTTY :  An  activity  that  contributes  to  the  outcome  or  output  of  a  process,  in  such 
a  way  that  the  processes'  customer  would  consider  the  activity  is  necessary. 
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Appendix  E  Attribute  Definitions 

ACCOUNTABLE-COMPONENT-NAME:  A  declarative  word  or  phrase  that  indicates  the  group  or 
organization  that  has  formal  or  official  financial  responsibility  for  the  INITIATIVE-ACTIVITY  (A  non¬ 
key  attribute  of  INITIATIVE-ACT) 

ACCOUNTABLE-ORGANIZATION-ID:  A  unique  value  assigned  to  identify  a  specific 

ORGANIZATIONAL-UNIT  within  a  COMPONENT  organization  that  has  formal  or  official  financial 
responsibility  for  the  INITIATrVE-ACTrVITY.  (A  non-key  attribute  of  INITIATIVE-ACT) 

ACTIVITY -MECHANISM-TT - FOCUS :  A  characteristic,  whose  values  are  either  yes  or  no,  that  qualifies 
a  mechanism  as  of  interest  to  those  collecting  information  technology  costs.  (A  non-key  attribute  of  the 
entity  ACTIVITY-MECHANISM.  Used  as  a  discriminator  for  the  category  entity  IT-MECHANISM) 

ACTIVITY -MODEL-AUTHOR-NAME:  A  declarative  word  or  phrase  that  differentiates  an  instance  of 
an  individual  or  group,  that  created  a  specific  instance  of  ACTIVITY-MODEL,  from  another  individual 
or  group.  (A  non-key  attribute  of  ACTTVITY-MODEL-VERSION) 

ACTIVITY -MODEL-CREATION-DATE:  The  specific  point  in  time  (allowing  fractions  of  a  second) 
when  an  instance  of  ACTIVITY-MODEL  was  created.  (A  non-key  attribute  of  ACTIVITY-MODEL- 
VERSION) 

ACTIVITY -MODEL-LIFE-CYCLE-STEP.  The  development  stage  which  an  instance  of  ACTIVITY- 
MODEL  has  achieved  (e.g.,  working,  draft,  recommended,  published).  (A  non-key  attribute  of 
ACTIVITY-MODEL) 

ACTIVITY-MODEL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an 
ACTIVITY-MODEL  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  native  to 
ACTIVITY-MODEL) 

A  CTIVITY-M OD EL-PROJECT-ID:  A  unique  value  assigned  to  identify  the  project  that  is  associated  with 
an  instance  of  ACTIVITY-MODEL.  (A  non-key  attribute  of  ACTIVITY-MODEL) 

ACTIVITY -MODEL-PURPOSE:  The  objective  for  which  a  business  process  was  documented  within  an 
ACTIVITY-MODEL-VERSION.  (A  non-key  attribute  of  ACTIVITY-MODEL-VERSION) 

A  CTIVITY -MODEL-REVISION-DA  TE:  The  specific  point  in  time  (allowing  fractions  of  a  second)  when 
changes  to  an  instance  of  ACTIVITY-MODEL  occurred.  (A  non-key  attribute  of  ACTIVITY-MODEL- 
VERSION) 

ACTIVITY -MODEL-SCOPE:  The  breadth  and  depth  of  a  subject  area  being  represented  within  an 
ACTIVITY-MODEL.  (A  non-key  attribute  of  ACTIVITY-MODEL-VERSION) 

ACTIVITY -MODEL-SHORT-NAME:  A  word  or  phrase  that  is  usually  an  abbreviated  or  truncated 
version  of  the  ACTIVITY-MODEL-NAME.  (A  non-key  attribute  of  ACTIVITY-MODEL) 
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ACTIVITY -MODEL-SYSTEM-ID\  A  unique  value  assigned  to  identify  a  system  associated  with  an 
instance  of  ACTIVITY-MODEL.  (A  non-key  attribute  of  ACTIVITY-MODEL) 

A  CTIVITY-MODEL-TA SK -NUMBER :  A  unique  value  assigned  to  an  ACTIVITY-MODEL  for  modeling 
project  control.  (A  non-key  attribute  of  ACTIVITY-MODEL) 

ACTIVITY-MODEL-VERSION-ID :  An  ACTIVITY-MODEL  may  change  over  time.  The  ACTTVITY- 
MODEL-VERSION-ID  identifies  the  particular  iteration  of  the  model.  (A  key  owned  by  the  entity 
ACTIVITY-MODEL-VERSION) 

ACTIVITY-MODEL-VIEWPOINT:  The  perspective  from  which  a  business  area  is  defined  within  an 
ACTIVITY-MODEL.  (A  non-key  attribute  of  ACTIVITY-MODEL-VERSION) 

ACTIVITY -NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an  ACTIVITY  from 
another  (to  someone  familiar  with  the  subject  area).  (A  key  owned  by  the  entity  ACTIVITY) 

ACTIVITY -VERSION-ID:  A  unique  value  assigned  to  an  instance  of  ACTIVITY  that  indicates  the 
iteration  of  the  activity.  (A  key  attribute  owned  by  the  entity  ACTIVITY-VERSION) 

ACTIVITY-WORKLOAD-FISCAL-YEAR:  Per  annum  accounting  period,  spanning  October  1  through 
September  30,  that  applies  to  a  specific  instance  of  ACTIVITY-WORKLOAD.  (A  key  attribute  owned 
by  the  entity  ACTIVITY-WORKLOAD) 

ACTUAL-ACTIVITY-WORKLOAD-AMOUNT:  The  demonstrated  volume,  quantity,  cost,  etc.  of  the 
ACTIVITY-CONTROL  that  triggers  the  ACTIVITY-WORKLOAD.  (A  non-key  attribute  of  the  entity 
ACTIVITY-WORKLOAD) 

ACTUAL-PERFORMANCE-AMOUNT:  The  demonstrated  volume,  quantify,  cost,  etc.  per  the 
PERFORMANCE-OBJECTIVE.  (A  non-key  attribute  of  the  entity  PERFORMANCE-ACHIEVEMENT) 

AGREEMENT-ID:  A  unique  value  assigned  to  identify  an  instance  of  AGREEMENT.  (A  key  attribute 
owned  by  the  entity  AGREEMENT) 

ALTERNATIVE-DESIGNATION:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an 
FUNCTIONAL-ALTERNATIVE  from  another  (to  someone  familiar  with  the  subject  area).  (A  key 
attribute  owned  by  the  entity  FUNCTIONAL-ALTERNATIVE) 

APPROPRIA  TION-LIMTTA  TION-CODE:  A  parametric  value  used  to  constrain  budget  preparation  and 
execution.  (A  non-key  attribute  owned  by  the  entity  APPROPRIATION) 

APPROPRIATION-PURPOSE:  The  Congressionally  defined  or  approved  intention  for  which  the  funds 
are  to  be  allocated.  (A  key  attribute  owned  by  the  entity  APPROPRIATION) 

APPROPRIATION-TITLE:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an 
APPROPRIATION  from  another  (to  someone  familiar  with  the  subject  area).  (An  alternate  key  attribute 
owned  by  the  entity  APPROPRIATION-FUND-SOURCE) 
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B UNDLED-IC OM-NA ME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  summary- 
level  ICOM  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity 
COMPONENT-ICOM,  using  a  role  name  for  ICOM-NAME) 

COMPONENT-ACTIVITY -NAME:  Depicts  an  ACTIVITY-NAME  as  a  member  of  an  activity  tree  (node 
tree)  but  it  cannot  be  the  apextual  node.  (A  key  attribute  of  the  entity  COMPONENT-ACTIVITY,  using 
a  role  name  for  ACTIVITY-NAME) 

COMPONENT-ICOM-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  branch- 
level  ICOM  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  die  entity 
COMPONENT-ICOM,  using  a  role  name  for  ICOM-NAME) 

COMPONENT-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  COMPONENT 
from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  for  the  entity  COMPONENT) 

CONTROL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  CONTROL  from 
another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity  ACTIVITY-CONTROL, 
using  a  role  name  for  ICOM-NAME) 

DEFENSE-SUB-PROGRAM-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a 
DEFENSE-SUB-PROGRAM  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute 
owned  by  the  entity  DEFENSE-SUB-PROGRAM) 

DOD-COMPONENT-ACTIVITY-CIVILIAN-LABOR-AMOUNT:  The  cost  of  civilian  labor  provided  by 
a  DoD  Service  or  Agency  associated  with  a  single  instance  of  an  INITIATIVE-ACTIVITY,  encumbered 
by  the  INITIATIVE-ACTIVITY-WORK-PERFORMER.  (A  non-key  attribute  owned  by  the  entity  DOD- 
COMPONENT-SUPPLY-SOURCE.) 

DOD-COMPONENT-ACTIVITY -MILITARY -LABOR-AMOUNT:  The  cost  of  military  labor 
provided  by  a  DoD  Service  or  Agency  associated  with  a  single  instance  of  an  INITIATIVE-ACTIVITY, 
encumbered  by  the  INITIATIVE-ACTIVITY-WORK-PERFORMER.  (A  non-key  attribute  owned  by  the 
entity  DOD-COMPONENT-SUPPLY-SOURCE.) 

DOD-MISSION:  The  overall  task  or  purpose  assigned  to  an  activity,  agency  or  organization.  (A  non-key 
attribute  of  ACTIVITY-MODEL-VERSION) 

DRIVER-DESIGNA  TION:  A  declarative  word  or  phrase  that  differentiate*  one  instance  of  a  DRIVER 
from  another  (to  someone  familiar  with  the  subject  area).  (A  key  owned  by  die  entity  DRIVER) 

DRIVER-FOCUS:  The  concentration  of  an  instance  of  a  DRIVER.  (A  non-key  attribute  owned  by  the 
entity  ACTIVITY-DRIVER.  Used  as  a  discriminator  for  the  category  entities  COST-DRIVER, 
SCHEDULE-DRIVER,  and  PERFORMANCE-DRIVER) 

EFFeCTTVE-A  CTIVITY -MODEL-VERSION:  Indicates  the  first  version  of  the  activity  model  that  will 
no  longer  use  this  activity.  (A  non-key  attribute  of  the  entity  DISCONTINUED-ACTIVITY,  using  a  role 
name  for  ACTIVITY-MODEL-VERSION) 
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EFFECTIVITY -FOCUS:  A  characteristic  that  identifies  the  presence  of  an  activity  in  a  model  version 
to  those  involved  in  managing  change.  (A  non-key  attribute  of  the  entity  MODEL-ACTIVITY,  used  as 
a  discriminator  for  the  categoiy  entities  DISCONTINUED-ACTIVITY,  INTRODUCED-ACTTVITY,  and 
REPLACEMENT-ACTIVITY) 

FUNCTIONAL-ACTIVITY -MODEL-NAME:  A  declarative  word  or  phrase  that  differentiates  one 
instance  of  a  model  of  a  Functional  Activity  from  another.  (A  key-attribute  of  the  entity  FUNCTIONAL- 
ACTIVITY,  using  a  role  name  for  ACTIVITY-MODEL-NAME) 

FUNCTIONAL-ALTERNATIVE-STATUS :  A  word  or  phrase  that  indicates  the  current  condition  of  a 
FUNCTIONAL-ALTERNATIVE  (e.g.,  approved).  (A  non-key  attribute  owned  by  the  entity 
FUNCTIONAL-ALTERNATIVE) 

FUNCTIONAL-AREA-MODEL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance 
of  a  model  of  a  Functional  Area  from  another.  (A  key-attribute  of  the  entity  FUNCTIONAL-AREA, 
using  a  role  name  for  ACTIVITY-MODEL-NAME) 

FUNCTIONAL-REQUTREMENT-DESIGNA  TION:  A  declarative  word  or  phrase  that  one  differentiates 
instance  of  a  FUNCTIONAL-REQUIREMENT  from  another  (to  someone  familiar  with  the  subject  area). 
(A  key  attribute  owned  by  the  entity  FUNCTIONAL-REQUIREMENT) 

FUNDING-SOURCE-FISCAL-YEAR-.  Per  annum  accounting  period,  spanning  October  1  through 
September  30,  that  applies  to  a  specific  instance  of  FUNDING-SOURCE.  (A  key  attribute  owned  by  the 
entity  FUNDING-SOURCE) 

FUNDING-SOURCE-PURPOSE:  The  defined  or  approved  intention  for  which  the  funds  are  to  be 
allocated.  (A  key  attribute  owned  by  the  entity  FUNDING-SOURCE) 

FUNDING-SOURCE-TYPE:  A  taxonomic  characteristic  that  differentiates  one  kind  of  FUNDING- 
SOURCE  from  another.  (A  non-key  attribute  owned  by  the  entity  FUNDING-SOURCE.  Used  as  a 
discriminator  for  the  category  entities  APPROPRIATION-FUND-SOURCE  and  REVOLVING-FUND- 
SOURCE) 

ICOM-A  UTHOR-NAME:  A  declarative  word  or  phrase  that  indicates  the  individual  or  group  that  created 
an  instance  of  ICOM.  (A  non-key  attribute  owned  by  the  entity  ICOM-VERSION) 

ICOM-CREA  TION-DA  TE:  The  specific  point  in  time  (allowing  fractions  of  a  second)  when  an  instance 
of  ICOM  was  developed  or  originated.  (A  non-key  attribute  owned  by  the  entity  ICOM-VERSION) 

ICOM-DEFTNTTION:  The  designated  meaning  of  an  instance  of  an  ICOM-VERSION.  (A  non-key 
attribute  owned  by  the  entity  ICOM-VERSION) 

ICOM-NAME :  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an  ICOM  from  another 
(to  someone  familiar  with  the  subject  area).  (A  key  attribute  owned  by  the  entity  ICOM) 

ICOM-REVISION-DA  TE:  The  specific  point  in  time  (allowing  fractions  of  a  second)  when  an  instance 
of  ICOM  was  altered.  (A  non-key  attribute  owned  by  the  entity  ICOM-VERSION) 
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ICOM -TYPE.  Identifies  the  ICOM  as  an  INPUT,  CONTROL,  OUTPUT,  or  MECHANISM.  (A  non-key 
attribute  of  ACTIVITY  -ICOM  used  as  a  discriminator  for  the  category  entities  ACTIVITY-MECHANISM 
and  ACTIVITY-CONTROL) 

ICOM-VERS ION-ID.  A  unique  value  assigned  to  an  instance  of  ICOM-VERSION.  (A  key  attribute 
owned  by  the  entity  ICOM-VERSION) 

IMPROVEMENT-IMPACT-FOCUS:  A  characteristic  that  identifies  an  improvement  as  outside  the  area 
of  scope  from  the  perspective  of  those  involved  in  determining  process  improvements.  (A  non-key 
attribute  of  the  entity  IMPROVEMENT-OPPORTUNITY-IMPACT,  used  as  a  discriminator  for  the 
category  entity  EXTERNAL-IMPROVEMENT-IMPACT) 

IMPRO VEMENT-OPPOR  TUNITY -DESIGN A  TION:  A  declarative  word  or  phrase  that  differentiates  one 
instance  of  an  IMPROVEMENT-OPPORTUNITY  from  another  (to  someone  familiar  with  the  subject 
area).  (A  key  attribute  owned  by  the  entity  IMPROVEMENT-OPPORTUNITY) 

IMPROVEMENT-OPPORTUNITY-IMPACT-DESCRIPTION:  A  declarative  word  or  phrase  that 
differentiates  one  instance  of  an  IMPROVEMENT -OPPORTUNITY-IMPACT  from  another  (to  someone 
familiar  with  the  subject  area).  (A  key  attribute  owned  by  the  entity  IMPRO  VEMENT-OPPORTUNITY- 
IMPACT) 

INITIATIVE-ACCEPTANCE-CRITERIA:  The  standards  used  to  measure  the  accomplishment  of  an 
INITIATIVE.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE) 

INITIATIVE-ACTIVITY-CIVILIAN-LABOR-AMOUNT:  The  cost  of  civilian  labor  associated  with  a 
single  instance  of  an  INITIATIVE-ACTIVITY,  encumbered  by  the  INITIATIVE-ACTIVITY-WORK- 
PERFORMER.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY-WORK-RESOURCE- 
POOL) 

INITIATIVE-ACTIVITY-COMPONENT-NAME:  A  declarative  word  or  phrase  identifying  the  DoD 
Service  or  Agency  responsible  for  completing  the  INITIATIVE-ACTIVITY.  (A  key  attribute  of  the  entity 
INITIATIVE-ACTIVITY-WORK-PERFORMER,  using  a  role  name  for  COMPONENT-NAME) 

INITIA  TIV E-ACTIVITY  -CYCLE-TIME:  The  specific  amount  of  time  (allowing  fractions  of  a  second) 
over  which  an  instance  of  INITIATIVE-ACTIVITY  is  performed.  (A  non-key  attribute  owned  by  the 
entity  INITIATIVE-ACTIVITY) 

INITIATIVE-ACTIVITY-EQUIPMENT-AMOUNT:  The  cost  of  the  equipment  utilized  to  complete  a 
single  instance  of  an  INITIATIVE-ACTIVITY,  encumbered  by  the  INITIATIVE-ACTIVITY-WORK- 
PERFORMER.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY-WORK-RESOURCE- 
POOL) 

INITIA  TIVE-ACTIVITY -FACILITY -AMOUNT:  The  cost  of  the  facilities  utilized  to  complete  a  single 
instance  of  an  INITIATIVE-ACTIVITY,  encumbered  by  the  INITIATIVE-ACTIVITY-WORK- 
PERFORMER.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY-WORK-RESOURCE- 
POOL) 
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INITIA  TIVE-A  CTIVITY-LIFE-C Y CLE-COS T-ELEMENT-ID:  A  unique  value  assigned  to  an  instance 
of  INITIATIVE-ACTIVITY-WORK-PERFORMER  that  indicates  the  associated  life  cycle  cost  element. 
(An  alternate  key  owned  by  the  entity  INITIATIVE-ACTIVITY-WORK-PERFORMER) 

INULA  TIVE-A  CTIVUY-MA  TERIA  L-A  MO  UNT :  The  cost  of  the  materials  utilized  to  complete  a  single 
instance  of  an  INITIATIVE-ACTIVITY,  encumbered  by  the  INITIATIVE-ACTIVITY-WORK- 
PERFORMER.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY -WORK-RESOURCE- 
POOL) 

INUIATIVE-ACTIVITY -MILESTONE-INDICATOR.  A  yes/no  value  that  shows  whether  an 
INITIATIVE-ACTIVITY  is  a  landmark  in  the  overall  completion  of  that  INITIATIVE.  (A  non-key 
attribute  owned  by  the  entity  INITIATIVE-ACTIVITY,  used  as  a  discriminator  for  the  category  entity 
INITIATIVE-ACTIVITY-MILESTONE) 

INULA  TIVE-A  C TIVUY -MILESTONES TA  TVS:  A  word  or  phrase  that  indicates  the  current  condition 
of  an  INITIATIVE-ACTIVITY  that  serves  as  a  landmark  in  the  overall  completion  of  an  INITIATIVE. 
(A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY-MILESTONE) 

INUIA  TIVE-A  C  TIVUY -MILUA  R  Y-LA  BOR-A  MO  UNT :  The  cost  of  military  labor  associated  with  a 
single  instance  of  an  INITIATIVE-ACTIVITY,  encumbered  by  the  INITIATIVE-ACTIVITY-WORK- 
PERFORMER.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY-WORK-RESOURCE- 
POOL) 

INUIA  TIVE-A  CTIVUY -MODEL-NAME:  A  declarative  word  or  phrase  that  identifies  the  ACTIVITY- 
MODEL  that  depicts  the  steps  required  to  complete  an  initiative.  (A  non-key  attribute  of  the  entity 
INITIATIVE,  using  a  role  name  for  ACTIVITY-MODEL-NAME) 

INUIA  TIVE-A  CTIVUY -VERSION-ID:  Identifies  the  particular  iteration  of  the  model  that  depicts  the 
steps  required  to  complete  an  initiative.  (A  non-key  attribute  of  the  entity  INITIATIVE,  using  a  role  name 
for  ACTIVITY-VERSION-ID) 

INUIATIVE-ACTIVITY -NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an 
INITIATIVE-ACTIVITY  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of 
the  entity  INITIATIVE-ACTIVITY,  using  a  role  name  for  ACTIVITY-NAME) 

INUIA TIVE-ACTIV UY -ORGANIZATION-ID:  A  unique  value  assigned  to  identify  the  DoD  Service 
or  Agency  responsible  for  completing  the  INrTLATrVE-ACTrVITY.  (A  key  attribute  of  the  entity 
INITIATIVE-ACTIVITY-WORK-PERFORMER,  using  a  role  name  for  ORGANIZATION-ID) 

INUIATIVE-ACTIVITY -OTHER-AMOUNT:  The  cost  of  performing  a  single  instance  of  an 
INITIATIVE-ACTIVITY,  other  than  labor,  facilities,  materials  and  information  technology,  encumbered 
by  the  INITLATIVE-ACTIVITY-WORK-PERFORMER.  (A  non-key  attribute  owned  by  the  entity 
INITIATIVE-ACTIVITY -WORK-RESOURCE-POOL) 

INUIA  TIVE-A  CTIVUY -PERFORM ANCE-CRUERIA :  The  standards  used  to  evaluate  the  performance 
of  an  INITIATIVE.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-ACTIVITY) 
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INITIATIVE-DESIGNATION:  A  declarative  word  or  phrase  that  one  differentiates  instance  of  an 
INITIATIVE  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  owned  by  the 
entity  INITIATIVE) 

INITIA  TIVE-IT-FOCUS:  A  characteristic  that  identifies  an  INITIATIVE-ACTIVITY-WORK- 
PERFORMER  as  being  Information  Technology-related.  (A  non-key  attribute  of  the  entity  INITIATIVE- 
ACTIVITY-WORK-PERFORMER) 

INITIA  TIVE-MA  JOR-S Y S TEM-DESIGNA  TION:  A  declarative  word  or  phrase  that  indicates  the  major 
automated  system  associated  with  an  instance  of  INITIATIVE.  (A  non-key  attribute  of  the  entity 
INITIATIVE) 

INITIATIVE-REQUIRED-COMPLETION-DATE:  The  specific  point  in  time  (allowing  fractions  of  a 
second)  when  an  instance  of  INITIATIVE  is  to  be  concluded.  (A  non-key  attribute  owned  by  the  entity 
INITIATIVE) 

INITIATIVES  TART-DATE:  The  specific  point  in  time  (allowing  fractions  of  a  second)  when 
implementation  of  an  instance  of  INITIATIVE  is  to  start  begin.  (A  non-key  attribute  owned  by  the  entity 
INITIATIVE) 

INITIA  TIVESUPPLY -EQUIPMENT-AMOUNT:  The  cost  of  the  equipment  utilized  to  complete  a  single 
instance  of  an  INITIATIVE-ACTIVITY,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned 
by  the  entity  INITIATIVE-SUPPLY-RESOURCE-POOL) 

INITIA  TTVES UPPL Y-GENERAL-ADMIN-AMOUNT:  The  cost  of  the  General  &  Administrative 
support  utilized  to  complete  a  single  instance  of  an  INITIATIVE-ACTIVITY,  obligated  to  a  SUPPLY- 
SOURCE.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-SUPPLY-RESOURCE-POOL) 

INTTIATIVESUPPLY -MATERIAL-AMOUNT:  The  cost  of  the  materials  utilized  to  complete  a  single 
instance  of  an  INITIATIVE-ACTIVITY,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned 
by  the  entity  INITIATIVE-SUPPLY-RESOURCE-POOL) 

INITIA  TIVESUPPLY -OTHER-AMOUNT:  The  cost  of  performing  a  single  instance  of  an  INITIATIVE- 
ACTIVITY,  other  than  labor,  facilities,  materials  and  information  technology,  obligated  to  a  SUPPLY- 
SOURCE.  (A  non-key  attribute  owned  by  the  entity  INITIATIVE-SUPPLY-RESOURCE-POOL) 

INITIATIVE-TYPE:  A  taxonomic  characteristic  that  differentiates  one  group  of  INITIATIVE  from 
another  group  of  INITIATIVE.  (This  attribute  is  a  place-holder  where  categories  to  the  entity 
INITIATIVE  may  be  added  in  the  future.)  (A  non-key  attribute  owned  by  the  entity  INITIATIVE) 

INPUT-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an  INPUT  from  another 
(to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity  ACTIVITY-INPUT,  using  a 
role  name  for  ICOM-NAME) 

IS-PARENT-ACTIV ITY :  A  yes/no  value  that  shows  whether  an  instance  of  MODEL-ACTIVITY  is  the 
next  higher  i’rvel  within  the  decomposition.  (A  non-key  attribute  of  MODEL-ACTIVITY  used  as  a 
discriminator  for  the  category  entities  LEAF-ACTIVITY  and  PARENT-ACTIVITY.) 
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IS-ROOT-ACTIVITY :  A  yes/no  value  that  shows  whether  an  instance  of  MODEL-ACTIVITY  is  the 
highest  level  within  the  decomposition.  (A  non-key  attribute  of  MODEL-ACTIVITY  used  as  a 
discriminator  for  the  category  entities  ROOT-ACTIVITY  and  COMPONENT-ACTIVITY.) 

LEAF-ACTIVITY -MODEL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a 
LEAF-ACTIVITY-MODEL  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute 
of  the  entity  LEAF-ACTIVITY-MODEL,  using  a  role  name  for  ACTIVITY-MODEL-NAME) 

LEAF-ACTIVITY -MODEL-VERSION-ID:  Identifies  the  particular  iteration  of  a  LEAF-ACTIVITY- 
MODEL.  (A  key  attribute  owned  by  the  entity  LEAF-ACTIVITY-MODEL,  using  a  role  name  for 
ACTIVITY-MODEL-VERSION-ID) 

LEAF-ACTIVITY -NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an  activity 
on  a  LEAF-ACTIVITY-MODEL  from  another  (to  someone  familiar  with  the  subject  area).  (A  key 
attribute  of  the  entity  LEAF-ACTIVITY-MODEL,  using  a  role  name  for  ACTIVITY-NAME) 

MAJOR-FORCE-PROGRA M-NA ME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of 
an  MAJOR-FORCE-PROGRAM  from  another  (to  someone  familiar  with  the  subject  area).  (A  key 
attribute  owned  by  the  entity  DEFENSE-PROGRAM) 

MAJOR-FORCE-PROGRAM-NUMBER :  A  unique  value  assigned  to  an  instance  of  MAJOR-FORCE- 
PROGRAM.  (An  alternate  key  owned  by  the  entity  DEFENSE-PROGRAM) 

MECHANISM-CIVILIAN-LABOR-AMOUNT:  The  recurring  cost  of  civilian  labor  for  a  single  instance 
of  an  activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM-RESOURCE-POOL) 

MECHANISM-EQUIPMENT-AMOUNT:  The  recurring  cost  of  the  equipment  required  for  a  single 
instance  of  an  activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM-RESOURCE-POOL) 

MECHANISM-FACILITY-AMOUNT:  The  recurring  cost  of  the  facilities  utilized  for  a  single  instance 
of  an  activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM-RESOURCE-POOL) 

MECHANISM-GENERAL-ADMIN-AMOUNT:  The  recurring  cost  of  General  and  Administrative  support 
required  for  a  single  instance  of  an  activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM- 
RESOURCE-POOL) 

MECHANISM-MATERIAL-AMOUNT:  The  recurring  cost  of  materials  for  a  single  instance  of  an 
activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM-RESOURCE-POOL) 

MECHANISM-MILITARY-LABOR-AMOUNT:  The  recurring  cost  of  military  labor  for  a  single  instance 
of  an  activity.  (A  non-key  attribute  owned  by  the  entity  MECHANISM-RESOURCE-POOL) 

MECHANISM-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  MECHANISM 
from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity  ACTIVITY- 
MECHANISM,  using  a  role  name  for  ICOM-NAME) 
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MECHANISM-OTHER-AMOUNT:  The  recurring  cost  of  performing  an  activity,  other  than  labor, 
facilities,  materials  and  information  technology.  (A  non-key  attribute  owned  by  the  entity  MECHANISM- 
RESOURCE-POOL) 

MECHANISM-SUPPLY-EQUIPMENT-AMOUNT:  The  cost  of  the  equipment  utilized  perform  an 
ACTIVITY,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned  by  the  entity  MECHANISM— 
SUPPLY-RESOURCE-POOL) 

MECHANISM-SUPPLY-GENERAL-ADMIN-AMOUNT:  The  cost  of  the  General  &  Administrative 
support  utilized  to  complete  an  activity,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned 
by  the  entity  MECHANISM-SUPPLY-RESOURCE-POOL) 

MECHANISM-SUPPLY-MATERIAL-AMOUNT:  The  cost  of  the  materials  utilized  to  complete  an 
activity,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned  by  the  entity  MECHANISM- 
SUPPLY-RESOURCE-POOL) 

MECHANISM-SUPPLY -OTHER-AMOUNT:  The  cost  of  performing  activity,  other  than  labor,  facilities, 
materials  and  information  technology,  obligated  to  a  SUPPLY-SOURCE.  (A  non-key  attribute  owned  by 
the  entity  MECHANISM-SUPPLY-RESOURCE-POOL) 

MECHANISM-SUPPLY-REQUIREMENT-DESCRIPTION:  A  definition  of  a  material  or  service 

provided  by  a  MECHANISM-SUPPLY-SOURCE  to  satisfy  the  need  of  a  specific  MECHANISM- 
SUPPLY-REQUIREMENT.  (A  key  attribute  owned  by  the  entity  MECHANISM-SUPPLY- 
REQUIREMENT) 

MECHANISM-TYPE:  Identifies  the  mechanism  as  belonging  to  one  of  two  categories:  an  organization, 
or  a  job  role.  (A  non-key  attribute  of  ACTIVITY-MECHANISM  used  as  a  discriminator  for  the  category 
entities  ORGANIZATION-MECHANISM  and  POSITION-MECHANISM) 

MODEL-FOCUS:  The  target  area  of  examination  for  which  the  ACTIVITY-MODEL  is  being  created. 
(A  non-key  attribute  of  the  entity  ACTIVITY-MODEL) 

OBJECT-CLASS-CODE:  A  unique  value  assigned  to  an  instance  of  FINANCIAL-RESOURCE-POOL 
that  identifies  transactions  of  the  Federal  Government  by  the  nature  of  goods  or  services  purchased.  (A 
key  attribute  owned  by  the  entity  FINANCIAL-RESOURCE-POOL) 

OR  GA  NIZA  TION-CIVILIA  N-FULL-  TIME-EQ  UIVA  LENT:  The  demonstrated  number  of  civilian  people, 
adjusted  for  seasonality,  cycles,  etc.,  supplied  by  an  organization  to  accomplish  the  activiw.  (A  non-key 
attribute  of  ORGANIZATION-MECHANISM) 

ORGANIZATION-ID:  A  unique  identifier  assigned  to  identify  an  ORGANIZATIONAL-UNIT.  (A  key 
attribute  owned  by  the  entity  ORGANIZATIONAL-UNIT) 

ORGANIZATION-MECHANISM-FOCUS:  Identifies  whether  an  ORGANIZATION-MECHANISM 
directly  contributes  to  or  supports  Information  Technology  actions  or  tasks.  (A  non-key  attribute  of  the 
entity  ORGANIZATION-MECHANISM,  used  as  a  discriminator  for  the  category  entity  IT- 
ORGANIZATION-MECHANISM) 
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ORGANIZATION-MILITARY-FULL-TIME-EQUIVALENT:  The  demonstrated  number  of  military 
people,  adjusted  for  seasonality,  cycles,  etc.,  supplied  by  an  organization  to  accomplish  the  activity.  (A 
non-key  attribute  of  ORGANIZATION-MECHANISM) 

ORGANIZATION-TYPE :  A  taxonomic  characteristic  that  differentiates  one  group  of 
ORGANIZATIONAL-UNIT  from  another  group  of  ORGANIZATIONAL-UNIT.  (This  attribute  is  a 
place-holder  where  categories  to  the  entity  ORGANIZATIONAL-TYPE  may  be  added  in  the  future.)  (A 
non-key  attribute  owned  by  the  entity  ORGANIZATIONAL-UNIT) 

OUTPUT-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  OUTPUT  from 
another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity  ACTIVITY-OUTPUT, 
using  a  role  name  of  the  attribute  ICOM-NAME) 

OUTPUT-TYPE:  A  taxonomic  characteristic  that  differentiates  one  group  of  ACTIVITY-OUTPUT  from 
another  group.  (A  non-key  attribute  of  the  entity  ACTIVITY-OUTPUT.  Used  as  a  discriminator  for  the 
category  entities  PRIMARY-OUTPUT  and  BY-PRODUCT.) 

PARENT-ACTIVITY -MODEL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of 
a  PARENT-ACTIVITY-MODEL  from  another  (to  someone  familiar  with  the  subject  area).  (A  key 
attribute  of  the  entity  PARENT -ACTIVITY  -MODEL,  using  a  role  name  for  ACTIVITY -MODEL-NAME) 

PARENT-ACTIVITY -MODEL-VERSION-ID:  Identifies  the  particular  iteration  of  a  PARENT- 
ACTIVITY-MODEL.  (A  key  attribute  owned  by  the  entity  PARENT-ACTIVITY-MODEL,  using  a  role 
name  for  ACTIVITY-MODEL-VERSION-ID) 

PERFORMANCE-MEASURE-NAME-,  A  declarative  word  or  phrase  that  indicates  the  criteria  for 
gauging  the  improvement  in  execution  of  an  activity  for  an  instance  of  a  PERFORMANCE-OBJECTIVE. 
(A  key  attribute  owned  by  the  entity  PERFORMANCE-MEASURE) 

PERFORMANCE-OBJECTIVE-CLASS:  Indicates  whether  a  PERFORMANCE-OBJECTIVE  is  of  a 
strategic  or  supporting  nature.  (A  non-key  attribute  of  the  entity  PERFORMANCE-OBJECTIVE,  used 
as  a  discriminator  for  the  category  entities  STRATEGIC-PERFORMANCE-OBJECTIVE  and 
SUPPORTING-PERFORMANCE-OBJECTIVE) 

PERFORM ANCEOBJECTIVE-FISCAL-Y EAR:  Per  annum  accounting  period,  spanning  October  1 
through  September  30,  that  applies  to  a  specific  instance  of  PERFORMANCE-OBJECTIVE.  (A  key 
attribute  owned  by  the  entity  PERFORMANCE-ACHIEVEMENT) 

PL  A  NNED-A  CTIVITY -WORKLOAD-AMOUNT:  The  projected  or  estimated  volume,  quantity,  cost,  etc. 
of  the  ACTIVITY-CONTROL  that  triggers  the  ACTIVITY-WORKLOAD.  (A  non-key  attribute  of  the 
entity  ACTIVITY-WORKLOAD) 

PLANNED-PERFORMANCEAMOUNT:  The  projected  or  estimated  volume,  quantity,  cost,  etc.  per  the 
PERFORMANCE-OBJECTIVE.  (A  non-key  attribute  of  the  entity  PERFORMANCE-ACHIEVEMENT) 
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POSTTION-CWILIA  N-FULL-TME-EQ  VIVA  LENT:  The  demonstrated  number  of  civilian  people, 
adjusted  for  seasonality,  cycles,  etc.,  needed  to  accomplish  the  activity.  (A  non-key  attribute  of 
POSITION-MECHANISM) 

POSITION-MILITARY -FULL-TIME-EQUIVALENT:  The  demonstrated  number  of  military  people, 
adjusted  for  seasonality,  cycles,  etc.,  needed  to  accomplish  the  activity.  (A  non-key  attribute  of 
POSITION-MECHANISM) 

POSITION-NAME :  A  declarative  word  or  phrase  that  differentiates  one  instance  of  a  POSITION  from 
another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  owned  by  the  entity  POSITION) 

PRECEDING-ACTIVITY -MODEL-VERSION-ID :  Identifies  the  iteration  of  the  activity  model  that  is 
being  transformed  by  a  new  version.  (A  key  attribute  of  the  entity  MODEL-ACTIVITY-TRANSITION- 
LINK,  using  a  role  name  for  ACTIVITY-MODEL-VERSION-ID) 

PRECEDING-ACTIVITY -NAME:  The  declarative  word  or  phrase  that  identifies  the  activity  that  is 
undergoing  transformation.  (A  key  attribute  of  the  entity  MODEL-ACTIVITY-TRANSITION-LINK, 
using  a  role  name  for  ACTIVITY-NAME) 

PRECEDING-INITIATIVE-ACTIVITY-NAME:  The  declarative  word  or  phrase  that  identifies  an 
INITIATIVE-ACTIVITY  as  the  previous  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the 
entity  INITIATrVE-ACTrVIT Y -LINK,  using  a  role  name  for  ACTIVITY-NAME) 

PRECEDING-INITIA  TIVE-DESIGNA  TION:  A  declarative  word  or  phrase  that  one  differentiates  instance 
of  an  INITIATIVE  from  another  (to  someone  familiar  with  the  subject  area),  as  it  relates  to  an 
INITIATIVE-ACTIVITY  that  is  the  previous  activity  in  a  sequence  of  activities.  (Non-key  attribute  of 
the  entity  INITIATIVE-ACTIVITY-LINK,  using  a  role  name  for  INITIATIVE-DESIGNATION) 

PRECEDING-PROCESS-ACTIVITY -MODEL-NAME:  The  word  or  phrase  that  identifies  the 
ACTIVITY-MODEL  that  an  initiative  is  trying  to  accomplish,  as  it  relates  to  an  INITIATIVE-ACTIVITY 
that  is  the  previous  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the  entity  INITIATIVE- 
ACTIVIT  Y -LINK,  using  a  role  name  for  ACTIVITY  -MODEL-NAME) 

PRECEDING-PROCESS-ACTIVITY-MODEL-VERSION-ID:  Identifies  the  iteration  of  an  ACTIVITY- 
MODEL  that  an  initiative  is  trying  to  accomplish,  as  it  relates  to  an  INITIATIVE-ACTIVITY  that  is  the 
previous  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the  entity  INITIATIVE-ACTIVITY  - 
LINK,  using  a  role  name  for  ACTIVITY-MODEL-VERSION-ID) 

PRIM  ARY -OUTPUT-TYPE:  A  taxonomic  characteristic  that  differentiates  one  group  of  PRIMARY- 
OUTPUT  from  another  group.  (A  non-key  attribute  of  the  entity  PRIMARY-OUTPUT.  Used  as  a 
discriminator  for  the  category  entities  SERVICE-OUTPUT  and  PRODUCT-OUTPUT.) 

PRIOR-COMPONENT-ACTIVITY-NAME:  The  identification  of  one  component  in  its  place  in  a  series 
or  sequence  of  peer  activities.  (A  key  attribute  of  the  entity  COMPONENT-ACTIVITY,  using  a  role 
name  for  ACTIVITY-NAME) 
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PROGRAM-ELEMENT-CODE-.  A  unique  value  assigned  to  an  instance  of  PROGRAM-ELEMENT.  It 
contains  information  that  identifies  a  program-element  and  the  Miyor  Force  Program  and  Component 
responsible  for  that  program-element.  (An  alternate  key  owned  by  the  entity  PROGRAM-ELEMENT) 

PROGRAM-ELEMENT-NAME-.  A  declarative  word  or  phrase  that  differentiates  one  instance  of  an 
PROGRAM-ELEMENT  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  owned 
by  the  entity  PROGRAM-ELEMENT) 

REVOLVING-FUND-PURPOSE:  The  defined  or  approved  intention  for  which  the  revolving  funds  are 
to  be  allocated.  (A  key  attribute  owned  by  the  entity  REVOLVING-FUND-SOURCE,  using  a  role  name 
for  the  attribute  FUNDING-SOURCE-PURPOSE) 

ROOT-ACTIVITY -NAME:  The  declarative  word  or  phrase  that  differentiates  one  instance  of  ROOT- 
ACTIVITY  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the  entity 
ROOT-ACTIVITY,  using  a  role  name  of  the  attribute  ACTIVITY-NAME) 

ROOT-A  CTIVITY -NUMBER:  The  specific  ACTIVITY  that  serves  as  the  parent  or  top-most  ACTIVITY 
within  a  model.  (A  non-key  attribute  of  ACTIVITY-MODEL-VERSION) 

STRATEGIC-GOAL-NAME:  A  declarative  word  or  phrase  that  differentiates  one  instance  of 
STRATEGIC-GOAL  from  another  (to  someone  familiar  with  the  subject  area).  (A  key  attribute  of  the 
entity  STRATEGIC-GOAL) 

STRA  TEGIC-PERFORMANCE-MEASURE-NAME:  A  declarative  word  or  phrase  that  indicates  the 
criteria  for  gauging  the  improvement  in  execution  of  an  activity  for  an  instance  of  a  STRATEGIC- 
PERFORMANCE-OBJECTIVE.  (A  key  attribute  of  the  entity  STRATEGIC-PERFORMANCE- 
OBJECTIVE,  using  a  role  name  for  the  attribute  PERFORMANCE-MEASURE-NAME) 

SUCCEEDING-A  CTIVITY -MODEL-VERSION-ID:  The  activity  model  version  that  is  the  result  of  a 
change  to  the  activities.  (A  key  attribute  of  the  entity  ACTIVITY-TRANSITION-LINK,  using  a  role 
name  for  ACTIVITY-MODEL-VERSION-ID) 

SUCCEEDING-ACTIV TTY -NAME:  The  activity  that  is  the  result  of  implementing  changes  to  a  similar 
activity  in  a  prior  model  version.  (A  key  attribute  of  the  entity  ACTIVITY-TRANSITION-LINK,  using 
a  role  name  for  ACTIVITY-NAME) 

S UCCEEDING-INITIA  TIVE-ACTIVITY-NAME:  The  declarative  word  or  phrase  that  identifies  an 
INITIATIVE-ACTIVITY  as  the  subsequent  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the 
entity  INITLATIVE-ACTIVITY-LINK,  using  a  role  name  for  ACTIVITY-NAME) 

SUCCEEDING-INITIATIVE-DESIGNATION:  A  declarative  word  or  phrase  that  one  differentiates 
instance  of  an  INITIATIVE  from  another  (to  someone  familiar  with  the  subject  area),  as  it  relates  to  an 
INITIATIVE-ACTIVITY  that  is  the  subsequent  activity  in  a  sequence  of  activities.  (Non-key  attribute 
of  the  entity  INITLATIVE-ACTIVITY-LINK,  using  a  role  name  for  INITIATIVE-DESIGNATION) 
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SUCCEEDING-PROCESS-A  CTIVITY -MODEL-NAME:  The  word  or  phrase  that  identifies  the 
ACTIVITY-MODEL  that  an  initiative  is  trying  to  accomplish,  as  it  relates  to  an  INITIATIVE-ACTIVITY 
that  is  the  subsequent  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the  entity  INITLATIVE- 
ACTIVIT  Y  -LINK,  using  a  role  name  for  ACTIVITY  -MODEL-NAME) 

SUCCEEDING-PROCESS-A  CTIVITY -MODEL-VERSION-ID:  Identifies  the  iteration  of  an  ACTIVITY- 
MODEL  that  an  initiative  is  trying  to  accomplish,  as  it  relates  to  an  INITIATIVE-ACTIVITY  that  is  the 
subsequent  activity  in  a  sequence  of  activities.  (Non-key  attribute  of  the  entity  INITIATIVE-ACTIVITY  - 
LINK,  using  a  role  name  for  ACTIVITY-MODEL-VERSION-ID) 

SUPPLIER-CAGE-CODE:  A  unique  value  assigned  to  an  instance  of  a  commercial,  DoD,  or  other 
government  agency  source  of  supply.  (A  key  attribute  native  to  the  entity  SUPPLIER) 

SUPPLIER-TYPE:  Identifies  a  SUPPLIER  as  DoD,  Non-DoD-Govemment  or  contractor.  (A  non-key 
attribute  of  SUPPLIER  used  as  a  discriminator  for  the  category  entities  DOD-SUPPLY-SOURCE,  NON- 
DOD-GOVERNMENT-SUPPLY-SOURCE  and  CONTRACTOR-SUPPLY-SOURCE) 

SUPPLY-REQUIREMENT-DESCRIPTION:  A  definition  of  a  material  or  service  provided  by  a 
SUPPLY-SOURCE  to  satisfy  the  need  of  a  specific  TECHNICAL-SUPPLY-REQUIREMENT.  (A  key 
attribute  owned  by  the  entity  TECHNICAL-SUPPLY-REQUIREMENT) 

TECHNICALS PECIFICA  TION-A CCEPTANCE-CRITERJA :  The  minimum  measure  allowable  to 
comply  with  an  instance  of  TECHNICAL-SPECIFICATION.  (A  non-key  attribute  owned  by  the  entity 
TECHNICAL-SPECIFICATION) 

TECHNICALSPECIFICA  TION-PERPORMANCE-CRITERJA :  The  standards  used  to  evaluate  the 
performance  of  a  product  or  service  described  within  the  TECHNICAL-SPECIFICATION.  (A  non-key 
attribute  owned  by  the  entity  TECHNICAL-SPECIFICATION) 

TREASURYSYMBOL:  A  code  used  by  the  Department  of  Treasury  to  uniquely  identify  an  instance  of 
APPROPRIATION.  (An  alternate  key  owned  by  the  entity  APPROPRIATION) 

UNIT-IDENTIFICATION-CODE  (UIC):  The  unique  value  assigned  to  an  instance  of 

ORGANIZATIONAL-UNIT.  (An  alternate  key  owned  by  the  entity  ORGANIZATIONAL-UNIT) 

VALUE-ADDED-INDICA  TOR:  Shows  whether  a  MODEL-ACTIVITY  has  been  determined  to  be  value 
added,  or  non-value  added.  (A  non-key  attribute  owned  by  the  entity  MODEL-ACTIVITY,  used  as  a 
discriminator  for  the  category  entities  VALUE-ADDED-ACTIVITY  and  NON-VALUE-ADDED- 
ACTIVITY) 
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Issue  Resolution  Kit 


Modeling  Issue  Title 


States  Issue 


Tooth-to-Tail 


closed 


Description  of  Issue 


Tooth-To-Tail  is  the  ratio  between  operations  costs  over  management  and  support  costs. 
Theoretically,  the  higher  the  ratio,  the  better.  Operations  (Ops)  costs,  or  the  "tooth,"  are 
the  real  work  done  by  the  organization,  and  management  and  support  (M  &  S)  costs,  or  the 
"tail,"  are  in  effect,  the  organizational  costs.  Touch  labor  costs  or  direct  costs  are  types  of 
Ops  costs.  Overhead  costs  or  indirect  costs  are  types  of  M  &  S  costs. 

This  management  measure  has  demonstrated  little  value  to  FEA  practitioners,  as  it  is  not 
clear  how  to  divide  certain  costs  or  activities  between  Ops  or  M  &  S.  Sometimes  the  ratio 
is  misleading,  e.g.,  replacing  ten  million  dollars  of  non-value  added  Ops  activity  with  one 
million  dollars  of  value  added  M  &  S  activities  worsens  the  ratio. 

The  prevailing  opinion  suggests  replacing  the  Ops  to  M  &  S  cost  ratio  with  a  Value  Added 
to  Non-Value  Added  cost  ratio.  Non-value  added  costs  are  those  caused  by  delay,  excess, 
or  variation.  This  follows  directly  from  the  classification  of  activities  done  in  preparation 
of  the  FEA.  This  ratio  would  not  require  identifying  direct  versus  indirect  costs. 

Another  related  suggestion  applies  to  the  discussion  of  cost  elements.  Could  all  FEA  costs 
roll  up  under:  civilian  labor,  military  labor,  all  other  variable,  or  all  fixed  cost  elements? 
This  flexible  budgeting  approach  seems  better  suited  to  a  functional  manger's  costing  needs. 


Participants 


Issue  Cross  References 


FEAM  Proposed  Cost  Structure 
Issue  7  -  FEAM 


Recommendations 


Drop  Tooth-to-Tail 

Replace  Ops  to  M&S  cost  ratio  with  value-added  to  non-value 
added  cost  ratio. 


Updates 


1  July  1993 
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Modeling  Issue  Tide 

Status 

133 

Labor  Cost  Element 

tabled 

2 

Description  of  Issue  _ _ _ _ 

A  group  should  meet  to  discuss  Labor  as  a  cost  element  in  the  FEAM.  In  examining  the 
Labor  cost  element,  there  are  a  couple  of  issues  that  need  to  be  addressed. 

A  full-time  employee  may  provide  support  to  a  number  of  activities.  The  labor  hours  are 
typically  allocated  to  the  activities  in  an  estimated  percentage.  The  accuracy  of  the 
percentages  decreases  as  the  level  of  detail  or  decomposition  increases.  The  figures  for 
leaf-node  activities  are  an  estimated  percentage  of  an  estimate.  The  group  should  reach  an 
agreement  on  the  level  of  accuracy  required  to  support  the  decision  maker  using  the  FEA. 

The  functionals  performing  FEA  have  questioned  the  placement  of  IT-related  labor  within 
the  cost  elements.  Some  FEA  practitioners  have  placed  these  labor  costs  in  the  Labor 
element,  and  others  have  placed  the  labor  costs  in  the  IT  cost  element.  The  correct 
placement  for  the  IT-related  labor  should  be  determined  and  the  guidance  disseminated  to 
future  FEA  practitioners.  Basic  rule:  if  you're  there  because  the  computer  is  there,  you're 
part  of  the  IT  cost;  if  the  computer  is  there  because  you're  there,  you're  part  of  the 
functional  cost. 


Participants 

Issue  Cross  References 

FEAM  Proposed  Cost  Structure 
Abstract  #8 

Issue  5  -  IT  Cost  Element 

Issue  7  -  FEAM 

Issue  13  -  Allocations 

Recommendations 

Updates 

1  July  1993 
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Modeling  Issue  Tide 


Material  Cost  Element 


States  Issue 


tabled  3 


Description  of  Issue 


Are  there  any  cases  when  throughput  material  is  considered  as  an  activity  cost? 

Throughput  material  is  that  which  is  processed  or  transformed  by  the  activity,  but  is  not 
actually  consumed  by  the  activity  (other  than  offal  or  waste  byproducts).  For  example, 
does  the  effort  (and  cost)  expended  in  procuring  one  box  of  paper  vary  from  the  effort 
needed  for  one  hundred  pallets  of  paper?  An  activity's  unit  cost  should  include  material 
used  in  its  performance,  not  the  object  it  is  acting  on.  Jack  Cloos  will  take  this  as  an  off¬ 
line  task  and  report  back. 

Consumed  material  accounting  treatment  is  difficult.  Some  functional  activities  have 
picked  an  industry  standard  to  account  for  inventory  maintenance  costs  (holding  costs)  and 
separated  cost  of  material  from  cost  of  handling  material  (material  overhead).  What  is  the 
role  of  these  costs  in  an  FEA? 

Some  material  uses  DBOF  as  it  source  and  others  do  not.  How  should  this  be  handled?  [S] 


Participants 

Issue  Cross  References 

FEAM  Proposed  Cost  Structure 
Abstract  #8 

Issue  7  -  FEAM 

Issue  8  -  Revolving  Fund 

Reco  mmendations 

Updates 

Clarify  through-put/consumed  guidance. 

1  July  1993 
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Modeling 

Issue  Title 

Status 

Issue 

Facilities  Cost  Element 

tabled 

B 

Description  of  Issue 

A  group  should  focus  on  the  cost  element  Facility.  The  Facility  costs  have  been  difficult 
to  for  functional  managers  to  obtain.  The  Facility  cost  element  within  the  FEAM  seems  to 
be  a  real  property  idea.  The  placement  of  facility  maintenance  costs  is  ambiguous  and 
needs  to  be  decided.  For  some  activities,  the  Facility  cost  element  may  be  of  little  interest, 
whereas  for  other  activities  it  may  be  a  major  are  of  expense. 

The  idea  of  "Capital  Budgeting"  and  depreciation  needs  to  be  explored  and  its  applicability 
to  the  FEAM  determined.  The  Comptroller  is  moving  toward  depreciation,  and  this  will 
change  the  significance  of  facilities  in  an  FEA. 


Participants 

Issue  Cross  References 

FEAM  Proposed  Cost  Structure 
Abstract  #8 

Issue  7  -  FEAM 

Recommendations 

Updates 

1  July  1993 
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Issue 

IT  (Information  Technology)  Cost  Element 

closed 

5 

Description  of  Issue 


IT  is  a  separate  cost  element  in  FEAM,  allowing  the  use  of  a  12%  deflator.  The  deflation 
assumption  may  not  always  hold  true.  The  GSA  schedule  shows  deflators  that  are  more 
conservative,  i.e.,  less  deflating. 

In  FEAM  version  2.3,  IT  means  cost  of  acquisitions  only,  that  is,  in-house  development 
should  be  included  in  Labor.  There's  a  question  about  what  cost  element  should  include 
the  cost  of  contracts?  In  the  unreleased  version  3.0,  IT  is  split  between  COTS  and  non- 
COTS  with  the  assumption  that  non-COTS  would  handle  contracts.  Is  this  valid? 

It  appears  that  IT  as  a  cost  element  is  too  limiting.  Could  we  discontinue  its  use  and 
instead  replace  with  a  breakout  of  IT  costs  that  are  subtotal  of  the  greater  functional  cost? 
This  could  be  accomplished  by  identifying  an  Initiative-Activity  as  an  IT  cost  through  the 
use  of  a  yes  or  no  attribute.  This  would  allow  us  to  determine  IT  costs  within  a  functional 
area. 

It  was  suggested  that  as  a  first  step,  we  use  the  IT  definition  on  page  B-l  of  Budget 
Guidance  Manual.  How  does  this  definition  of  IT  map  to  PA&E’s  Economic  Analysis 
requirements  [12]? 

Can  IT  be  identified  to  one  activity?  Information  systems  are  usually  identified  as  a 
mechanism  in  IDEFO  models.  Many  times  one  information  system  can  service  multiple 
activities,  requiring  allocations.  The  allocation  of  mechanisms  is  less  accurate  as  you  go 
down  in  level  of  detail  (decomposition),  as  one  begins  estimating  a  percent  of  another 
estimate.][2].  However,  information  systems  should  be  thought  of  as  functional  enablers, 
"benefiting"  the  activity  rather  than  the  outcome  [43]. 

A  guide  to  preparing  IT  cost  estimates  may  be  helpful.  A  suggestion  was  made  to  provide 
a  periodically  updated  compendium  of  unit  costs  for  IT  estimating  (workstation,  etc  ). 
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Participants 

Issue  Cross  References 

FEAM  Proposed  Cost  Structure 
IT-43 

Abstract  #8 

Issue  2  -  Labor  Cost  Element 

Issue  7  -  FEAM 

Issue  12  -  Information  Systems 
Issue  13  -  Allocations 

Recommendations 

Updates 

Drop  IT  cost  element. 
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Issue 

G&A  and  Other  Cost  Element 

closed 

6 

Description  of  Issue 


Incorporated  into  guidance  for  users  of  the  FEAM  in  conducting  and  FEA  should  be  a  rule 
that  the  total  figure  for  "other"  should  not  be  larger  than  the  other  cost  elements.  A  group 
should  meet  and  determine  3  or  4  common  subcategories  of  "other"  as  an  example  of  the 
types  of  cost  this  should  include.  It  has  been  suggested  that  a  limitation  or  constraint  be 
incorporated  into  the  software  that  limits  the  amount  of  "other"  permitted  (for  example, 
10%).  Another  option  would  require  a  detailed  explanation  of  the  "other"  category  costs  if 
the  amount  is  greater  than  a  certain  percentage  of  the  total  costs.  The  group  should  also 
address  the  G&A  cost  element,  determining  the  kinds  of  costs  that  are  appropriate  for  this 
category. 

/The  G&A  and  HQ  Support  of  Installations  categories  in  version  2.3  were  designed  to  take 
in  all  the  tail.  Version  3  of  the  FEAM  model  replaces  these  with  "G&A"  and  "Other". 

The  group  must  determine  how  these  categories  are  to  be  used. 


Participants 

Issue  Cross  References 

FEAM  Proposed  Cost  Structure 
Abstract  £8 

Issue  7  -  FEAM 

Recommendations 

Updates 

•  Drop  G&A  and  HQ  Support  of  Installations. 

•  Follow  Comptroller's  G&A  definitions. 

•  Place  constraint  on  "Other"  cost  element. 

1  July  1993 
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Status 

Issue 

FEAM 

modeled 

■ 

Description  of  Issue 


In  addition  to  incorporating  the  results  of  the  cost  element  groups,  the  group  given  the  task 
of  examining  the  FEAM  issues  should  specifically  address  the  following  issues: 


•  Who  are  the  customers? 

•  Should  Object  Classes  be  mapped  to  the  FEA  Cost  Elements?  A  preliminary  exhibit 
should  be  created,  with  participation  from  Joe  Romito. 

•  How  do  we  handle  risk? 

•  What  does  the  "decision  maker"  want  to  see  in  the  FEAM?  Does  s/he  want  to  see 
IT  broken  out? 

•  RDT&E  and  Investment  phases  of  work  are  sometimes  difficult  to  distinguish. 
Should  RDT&E  be  just  Development?  There  is  some  conflict  of  terms  between 
FEAM  and  OMB,  including  the  definition  of  RDT&E.  These  conflicts  should  be 
resolved. 


Participants 


Issue  Cross  References 


FEAM  Proposed  Cost  Structure 
Issue  1  -  Tooth-to-Tail 
Issue  2  -  Labor  Cost  Element 
Issue  3  -  Material  Cost  Element 
Issue  4  -  Facilities  Cost  Element 
Issue  5  -  IT  Cost  Element 
Issue  6  -  G&A  &  Other  Cost 
Element 


Recommendations 


Breakout  recurring  activities  and  one-time  (initiative)  activities. 


Updates 
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Status 

Issue 

Revolving  Fund 

modeled 
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Description  of  Issue 


Revolving  funds  include  DBOF  and  industrial  funding,  and  perhaps  fee-for-service  (e  g., 
DITSO). 

DBOF's  receive  initial  appropriations,  and  receive  replenishments  thereafter.  We  need  to 
deal  with  this  condition,  i.e.,  having  the  model  reflect  funds  outside  of  direct 
appropriations,  e.g.,  DLA:  Although  DLA  is  a  component,  they  operate  like  a  retail 
organization.  While  DBOF  and  its  unit  costing  concept  are  traceable  to  activity  costing. 
The  funds,  and  the  organizational  activities  which  operate  within,  that  go  into  the  DBOF 
are  no  longer  traced  to  an  appropriation. 

Some  material  uses  DBOF  as  it  source  and  others  do  not.  How  should  this  be  handled?  [3] 

How  do  you  capture  large  hardware/sofitware  purchases  that  are  not  project  specific.  How 
do  we  do  large  quantity  buys,  e  g.  USAF  computers,  and  charge  out  as  needed  (fee-for- 
service  idea).  What's  an  acquisition  and  what's  an  investment  (replacement  of  computers)? 
What  impact  is  caused  by  the  use  of  IDIQ  contracts? 

The  DBOF  is  an  issue  for  the  43  s  also,  as  Information  Management  funds  have  been 
shifted  to  DITSO.  Could  the  FEA  provide  the  prepares  of  43  series  exhibits  will  this  data 
[43]? 


Participants 


Issue  Cross  References 


IT-43 

Abstract  #9 

Issue  3  -  Material  Cost  Element 
Issue  15  -  Products  &  Services 


Recommendations 


Changed  entity  "Appropriation"  to  "Funding  Source" 


Updates 
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Issue 

FEA  Process 

open 

n 

Description  of  Issue 

The  impact  of  discoveries  and  issues  from  this  session  must  be  related  back  to  changes  in 
the  FEA  process.  Some  of  these  issues  include: 

Determining  the  appropriateness  of  figuring  reduced  headcount  projections.  It  may  be 
more  appropriate  to  implement  the  changes,  and  then  bring  in  a  Methods  Engineering 
Team  to  pull  the  cost  savings  out  of  the  budget. 

FEA  practitioners  should  capture  an  audit  trail  when  collecting  data  in  order  to  redefend 
the  FEA  model,  since  it  will  serve  multiple  purposes.  It  must  be  clear  where  the  initial 
data  came  from,  and  the  audit  trail  should  provide  an  understanding  of  the  data  flow, 
cost  schedules,  etc.  This  audit  trail  will  aid  functional  managers  to  enter  data  once  and 
use  it  many  times. 

Examine  the  impact  of  the  initiative  funding  process,  future  procurements,  etc.  There 
exists  a  number  of  approval  stovepipes,  any  of  which  could  be  a  disapproval  that  can 
cause  an  FEA  to  be  re-done.  This  is  another  supporting  argument  for  providing  an 
audit  trail. 

Discuss  the  concepts  of  re-engineering  vs.  incremental  improvement. 

FEA  Scoping/Order  of  Magnitude  issues:  how  deep  does  a  functional  manager  go? 

Lifetimes  of  an  FEA  vs.  an  activity  model.  Currently  getting  FEAs  that  don't  ever  go  back 
and  revisit  the  changes  that  were  made.  An  FEA  Baseline  is  the  same  as  MAISRC  status 
quo.  However,  AS-IS  activity  models  are  a  snapshot  at  the  time  they're  taken.  Incremental 
changes  can  use  transitional  TO-BE  models  to  help  synchronization. 

Terminology  issue:  what  does  "information  infrastructure"  mean? 

We  need  to  find  and  benchmark  other  equivalent  FPI  processes  in  other  agencies  or  in 
industry. 

Who  are  the  stakeholders  in  the  FEA  process?  MAISRC,  IT43s,  functional  managers,  IM 
environment. 

Where's  the  next  pilot  for  the  data  model  (maybe  acquisition?). 


How  are  nested  FEAs  reconciled? 
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Participants 

Issue  Cress  References 

Recommendations 

Updates 
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Issue 

Improvement  Opportunity  and  Benchmarking 

tabled 

10 

Description  of  Issue 

The  current  FPI  Business  Rule  model  does  not  depict  the  idea  of  Best  Business  Practices, 
or  Benchmarking.  Entities  representing  these  ideas  need  to  be  depicted,  and  their 
relationship  to  other  areas  explored.  Are  benchmarks  just  related  to  performance  measures? 

The  idea  of  an  entity  preceding  Improvement-Opportunity,  representing  the  issue,  problem, 
or  deficiency  discovered  that  led  to  the  Improvement-Opportunity,  should  also  be  explored 
and  depicted. 


Participants 

Issue  Cross  References 

Abstract  #1 

Recommendations 

Updates 

16  June  1993 
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Stains 

Issue 

Non-cost  Resource  Attributes  (demand/supply,  workload) 

modeled 

11 

Description  of  Issue 


A  group  should  explore  site  specific  costs  per  activity,  and  how  the  workload  is  divided 
between  activities  in  transition,  or  sites.  The  use  of  tables  or  screens  may  help  to  make 
this  clearer.  This  issue  would  probably  be  best  dealt  with  in  the  context  of  a  standard 
activity  costs  discussion  with  the  Comptroller,  primarily  regarding  the  FEA  update. 


Attributes  that  form  the  resource  pools  are  not  in  all  cases  identifiable  with  the  functional 
activities  that  the  manager  wants  to  manage.  We  currently  need  to  make  allocations,  which 
vary  in  degree  of  accuracy.  The  current  pools  may  be  too  big,  and  may  the  activity  may 
need  to  be  aggregated  higher,  or  the  pool  broken  down  lower.  The  overarching  issue  is 
that  the  current  accounting  structure  does  not,  in  most  cases,  match  the  functional 
areas/activities  outlined  by  CIM.  The  resolution  of  this  CIM  vs.  PPBS  issue  will  most 
likely  resolve  the  site  specific  cost  issue. 

The  group  should  identify  where  to  put  workload  projections  in  the  FPI  model. 

There  is  a  need  for  attributes  other  than  cost  to  depict  resource  needs,  such  as  Full-Time- 
Equivalent  (FTE).  The  attributes  would  most  likely  be  placed  in  the  entity  Mechanism- 
Resource-Pool. 


Participants 


Issue  Cross  References 

Abstract  #  2 
Abstract  #10 
Abstract  #12 

Issue  14  -  Strategic  Goal  Model 
Issue  15  -  Products  &  Services 
Issue  16  -  Miscellany 


Recommendations 

Updates 

Part  of  Core  Team  Modeling  Session 

23  June  1993 
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Issue 

Information  Systems 

closed 
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Description  of  Issue 

Information  systems  are  found  within  FEA  alternatives,  identified  as  initiatives.  Information 
systems  may  serve  more  than  one  functional  activity,  and  have  life  cycle  costs  beyond  their 
fielding. 

We  need  a  way  to  express  the  "rice  bowl"  for  each  major  system,  e.g.,  EDMICS.  There  is 
currently  no  modeled  attribute  that  identifies  it,  e  g.  EDMICS  vs.  CHCS. 

Place  an  optional  in  the  entity  Initiative  called  Major  System  Designation. 

It  was  suggested  that  as  a  first  step,  we  use  the  IT  definition  on  page  B-l  of  Budget 
Guidance  Manual.  How  does  this  definition  of  IT  map  to  PA&E's  Economic  Analysis 
requirements  [12]? 

Analyzing  supplier  relationships  may  help  us  understand  how  we  can  represent  Central 
Design  Activities,  and  43  series  reporting  needs.  [43] 

We  need  to  expand  the  Activity-Mechanism  categories,  and  allow  for  IT,  and  entities 
analogous  to  Supplier-Source  attached  to  initiatives. 

Supply-Source  entity:  Need  to  take  a  case  history  and  apply  to  this.  CAGE  code  may  be  a 
more  meaningful  attribute  than  the  Supply-Sequence-Number.  Probably  a  multi-valued 
attribute,  because  of  multiple  contract  possibility. 


Participants 

Issue  Cross  References 

Abstract  #6 

Abstract  #10 

Abstract  #1 1 

Abstract  #12 

Issue  17  -  Initiative  to  Recurring 
Activity  Linkage 

Recommendations 

Updates 

Only  "Initiative"  will  carry  characterization  as  a  "major  system 
designation." 

Recurring  activities  and  initiatives  now  have  similar  supplier,  etc. 
relationships. 

24  June  1993 
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Issue 

Allocations 

canceled 
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Description  of  Issue 

assssss . a  aaaesaaaaaaaaasaaaaaa . sasssssassasasssaagaas . : raa aaaaaaaaaaaaa . . 

The  team  discussed  work  done  in  this  area  by  Computer  Aided  Manufacturing  - 
International  (CAM-I),  which  said  a  driver  can  be  used  as  an  allocation  base  (e  g.  number 
of  head,  number  of  square  feet).  This  area  needs  some  substantiation  and  more  thinking 


Participants 

Issue  Cross  References 

Abstract  #2 

Issue  2  -  Labor  Cost  Element 

Issue  5  -  IT  Cost  Element 

Recommendations 

Updates 
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Status 

Issue 

Strategic  Goal  Model 

closed 

14 

Description  of  Issue _ _ 

Within  the  current  FPI  Enterprise  model,  strategic  goal  and  mission  are  linked  at  the  entity 
Activity-Model-Version.  They  are  not  tied  to  Performance-Measure.  There  can  actually  be 
more  than  one  goal  for  an  Activity-Model-Version.  The  Performance-Measure  should 
depict  how  well  a  goal  is  achieved.  A  new  entity,  perhaps  called  Strategic-Goal,  should  be 
linked  to  Performance-Measure. 

Functional  Area/Activity  is  not  depicted  in  the  model,  it  is  only  implied. 


Participants 

Issue 

Cross  References 

Abstract  #13 

Issue  1 1  -  Non-Cost  Resource 
Attributes 

Issue  15  -  Products  &  Services 
Issue  16  -  Miscellany 

Recommendations 

Updates 

Part  of  Core  Team  Modeling  Session 

23  June  1993 
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Status 

Issue 

Products  and  Services  Model 

modeled 

IS 

Description  of  Issue 

The  model  does  not  provide  for  products  or  services  resulting  from  modeled  activities 
(activity  output).  Would  this  aid  the  discussion  regarding  DITSO  type  fee-for-service 
concepts.  In  that  case,  it  would  indicate  one  activity's  output  becoming  another  activity's 
mechanism.  This  may  become  a  category  of  an  activity  model  output  ICOM. 

Products  and  services  related  to  workload  and  DITSO/Fee  for  Service  issues,  depend  on 
determining  the  handling  of  ops  activities  in  the  life  cycle;  costs  of  system,  system  charges, 
et  al.  [8] 


Participants 

Issue 

Cross  References 

Abstract  #12 

Issue  8  -  Revolving  Fund 

Issue  1 1  -  Non-Cost  Resource 
Attributes 

Issue  14  -  Strategic  Goal  Model 
Issue  16  -  Miscellany 

Recommendations 

Updates 

Part  of  Core  Team  Modeling  Session 

23  June  1993 
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Modeling  Issue  Tide 

Status 

Issue 

Miscellany 

modeled 
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Description  of  Issue 

Some  of  the  issues  discovered,  while  significant,  did  not  fall  into  a  major  issue  category. 

A  group  should  examine  these  singular  issues,  keeping  in  mind  any  potential  impact  to 
other  model  areas.  This  issues  are: 

•  Examine  and  resolve  whether  a  Program-Element  can  be  related  to  many 
Appropriations. 

•  Test  the  relationship  between  drivers  and  controls:  do  you  allow  a  control  that  doesn't 
have  a  driver?  Test  the  differences  between  driver  types.  Do  we  have  the  right  types? 
Are  they  redundant? 

•  Walk  an  example  of  an  FEA/EA  requirement  through  the  MAISRC  and  acquisition 
processes. 


Participants 

Issue  Cross  References 

Abstract  #5 

Abstract  #6 

Abstract  #9 

IT-43 

Recommendations 

Updates 

Incorporate  Driver/Control  issue  into  Core  Team  Modeling  Session 
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Issue 

Initiative  to  Recurring  Activity  Linkage  (benefits) 

modeled 

17 

Description  of  Issue  _ _ _ 

How  does  FEA  measure  a  return  on  investment  or  achieved  benefits?  Where  is  this 
obtained?  It's  not  in  the  current  43  series,  other  than  the  narratives.  What  functional 
changes  must  be  made,  and  what  is  the  benefit  from  these  changes.  FEA  depicts  savings 
as  a  change  to  the  functional  activity  baseline,  offset  by  investment  costs.  The  savings  is 
derived  through  FEA  preparers  timing  the  implementation  of  initiatives  to  reductions  in 
activity  costs.  However,  this  is  not  a  hard  linkage.  The  modeling  effort  needs  to  provide 
this  linkage,  possibly  paving  the  way  for  FEA  becoming  a  part  of  the  management 
reporting  structure  [43], 

What  comes  out  of  the  budget?  Benefits  are  not  always  about  dollars,  but  if  you  are  going 
to  show  dollar  savings,  show  real  dollar  reductions  [43],  How  do  we  reduce  the  noise  of 
analysis  change  on  budgets?  Need  to  have  a  tracking  signal  or  trigger  to  know  when  the 
savings  should  affect  the  budget. 

How  can  we  link  the  FEA  Model  to  the  43  series,  as  everything  in  the  43A-1  should  be  in 
the  FEA  somewhere  [43], 

The  concept  of  a  Functional  Area/Functional  Activity  was  supposed  to  act  like  industry's 
Business  Activities  (about  20).  We  may  not  need  to  have  1 12  as  a  reporting  requirement 
[43]. 

Should  information  systems  be  thought  of  as  functional  enablers,  "benefiting"  activities 
rather  than  outcomes?  Functional  savings  can  only  be  obtained  through  implementation  of 
complete  initiatives,  of  which  an  information  system  may  be  only  a  small  part.  This  is 
compounded  by  inclusion  of  an  information  system's  operational  activities  past  the  time 
fence  impacted  by  completion  or  fielding  of  initiatives.  These  operational  activities  are  not 
part  of  the  initiative,  but  are  considered  within  the  information  system's  life  cycle  [43], 

Examine  a  simple  or  complex  initiative  structure,  and  initiatives  as  they  come  on  line  and 
affect  existing  activities.  Load  these  examples  into  an  instance  table,  using  the  PA&E 
template. 

Related  to  products  and  services,  invites  the  question  of  the  benefits/impacts  to  the  other 
functional  areas  (perhaps  elevating  the  activity  model  abstraction,  or  the  "A-l"  idea)  in 
putting  guidance  together.  Address  costs,  benefits  and  responsibilities  of  an  initiative  to 
other  functional  activities,  aka  cross-functional  impacts. 
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We  need  to  model  the  concept  of  a  "process."  A  process  is  a  chain  of  activities  that  cuts 
across  organizational  boundaries.  Processes  may  not  be  apparent  at  the  higher  FEA  level, 
but  lower  at  TQM-targeted  levels,  as  a  process  level  activity  should  be  a  member  of  one 
business  process. 

We  need  to  understand  who  are  the  activity  and  process  stakeholders.  Who  is  the  proponent 
of  a  process,  since  a  process  may  cut  across  organizational  boundaries.  As  a  rule,  ail  value 
added  activities  have  more  than  one  stakeholder. 

Analyzing  what  type  of  data  is  used  within  the  life  cycle  cost  WBS  leads  us  to  finding  a 
way  to  tie  together  the  concepts  of  a  bill  of  materials  and  a  bill  of  activities  in  support  of 
the  WBS.  The  life  cycle  cost  element  structure  mixes  the  two  (activities  and  items).  Map  , 
to  the  initiative-activities  and  the  supply-source.  This  should  fit  the  MAISRC 
requirements.  We  need  to  test  this  area  of  the  model  and  how  it  fits  to  the  MAISRC 
requirements  very  carefully. 


Participants 

Issue  Cross  References 

Issue  12  -  Information  Systems 
Abstract  #6 

Recommendations  Updates 


Facilitation  team  to  develop  a  pro-forma  data  model,  to  be 
reviewed  by  Core  Team. 
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Appendix  G  Instance  Tables 


Initiative 


Initiative-Designation 

Increase  EDMICS 
User  Community 

Activity-Model-Name 

ITAP 

Activity-Modei-Version-ID 

TO-BE 

Initiative-Major-System  Designation 

EDMICS 

Initiative-Activity-Model-Name. 

Activity-Model-Name 

ITAP 

Ini  tiative-Activity-Model-Version-ID  Activity 
-Model-Version-ID 

AS-IS 

Initiative-Start-Date 

10/1/93 

Initiative-Required-Completion-Date 

9/30/97 

Initiative-Acceptance-Criteria 

text 

Initiative-Type 

Info  System 

Initiative-Activity 


Initiative-Designation 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Initiativc-Activity-Name.Activity  -Name 

Develop  Software 

Buy  Hardware 

Train  Users 

Activity-Model-Version-ID 

TO-BE 

TO-BE 

TO-BE 

Activity-Model-Name 

ITAP 

ITAP 

ITAP 

Accountablc-Component-Namc. Component- 
Name 

DLA 

DLA 

DLA 

Accountable-Organization-ID.Organization- 

ID 

DLA  CDA 
Columbus  (DLSO) 

DLA  CDA 
Columbus 

HQ 

Activity-Veraion-ID 

DISA/9/93 

DISA/9/93 

DISA/9/93 

Initiative-Activity -Cycle-Time 

36  months 

24  months 

12  months 

Initiative-Activity-Performance-Criteria 

Initiative-Activity-Milestone-Indicator 
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Initiative-Activity-Work- Performer 


I  Initial!  ve-Dewgnation 

Increase 

EDMICS  User 
Community 

Increase  EDMICS 
User  Community 

Increase 

EDMICS  User 
Community 

Mtiative-Activity-Name 

Develop  Software 

Buy  Hardware 

Train  Users 

Initiative-Aotivity-Coraponent-Name. 

Component-Name 

DISA 

DISA 

DISA 

Initiative-Activity-Organization-ID. 

Organization-ID 

DITSO 

DITSO 

DITSO 

■  Activity-Model-V erston-ID  : 

TO-BE 

TO-BE 

Activity-Model-Name 

ITAP 

ITAP 

ITAP 

Initiative-Activity-Life-Cycle-Cost-Element- 

ID 

2.022 

2.01 

2.05 

|  Initiative-IT-Focus 

Initiative-Activity-Work-Resource-Pool 


Component-Name 

DLA 

DLA 

DLA 

Major-Force -Program-Name 

Central  Supply  & 
Maintenance 

Central  Supply  & 
Maintenance 

Central  Supply 
&  Maintenance 

Ptogram-Btement-Name 

Supply  Ops 

Supply  Ops 

Supply  Ops 

Funding-Source-Budget-Fiscal-Year 

FY-94 

FY-94 

FY-94 

Funding -Source-Purpose 

Procurement 

Procurement 

Procurement 

Organization-ID 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

Object-Class-Code 

Acquisition  of 
Capital 

Equipment 

Acquisition  of 
Capita] 

Equipment 

Acquisition  of 
Capital 

Equipment 

Initiative-Designation 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Initiative-Activity-Name 

Develop  Software 

Buy  Hardware 

Train  Users 

initiative  - Activity-Component-Name 

DISA 

DISA 

DISA 

Initiative-Activity-Organization-ID 

DITSO 

DITSO 

DITSO 

Process-Activity -Model-Version-ID 

TO-BE 

TO-BE 

TO-BE 

Process-Activity -Model-Name 

ITAP 

ITAP 

ITAP 

Initiative-Activity -Civilian-Labor-Amount 

Initiative-Activity -Facility-Amount 

Initiative-Activity-Material-Amount 

Initiative-Activity-Military-Labor-Amount 

Initiative-Activity-Other-Amount 

Initiative-Activity-Equipment-Amount 

Initiative-Activity-Oenenl-Admin-Amount 
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Initiative-Suppiy-Agreement 


Initiative-Designation 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Initiative-Aotivity-Name 

Develop  Software 

Buy  Hardware 

Train  Users 

Initiative- Activity  -Component-Name 

DISA 

DISA 

DISA 

Imtiativc-Activity-Organization-ID 

DITSO 

DITSO 

DITSO 

Activity-Model-Veraiou-ID 

TO-BE 

TO-BE 

TO-BE 

Activity-Model-Name 

ITAP 

ITAP 

ITAP 

Supplier-CAGE-Code 

Agreement-ID 

Initiative-Supply-Assignmcnt 


Mtiative-Deiignation 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Initiative-Aotivity-Name 

.  :  .  •  • 

Develop 

Software 

Develop 

Software 

Develop 

Software 

Initiative-Activity-Coinponent-Name 

DISA 

DISA 

DISA 

Initiative-Activity -Organizatioo-ID 

DITSO 

DITSO 

DITSO 

Activity-ModeLVewi<m-ID 

AS-IS 

TO-BE 

TO-BE 

Activity-Model-Name 

ITAP 

ITAP 

ITAP 

Supplier-CAGB-Code 

Agreement-ID  " 

Stqjpty-Reipia^^ 

Near-Line  Mass 
Storage  Queue 

Document 

Retrieval 
Transaction  Set 

Near-Line  Mass 
Storage  Jukebox 
Robotic  Conrols 

Performance-Meaaure-Name 

Document 

Retrieval  Time 

Document 

Retrieval  Time 

Document 

Retrieval  Time 

Improvement-Opportunity-Designation 

Eliminate 

Handling 

Eliminate 

Handling 

Eliminate 

Handling 

Component-Name 

DLA 

DLA 

DLA 

Organizatioa-ID 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

Punotkmal-Requirement-Designatkm 

On-Line  Access 

On-Line  Access 

On-Line  Access 
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Technical-Specification 

Technical-Supply-Requirement 


Aotmfy*Mddc4-V«rakaJ^ID 

TO-BE 

TO-BE 

TO-BE 

Supply  -Requireme  nt-Dc  scriptio  n 

Supercomputer 

Robotic  Cassette 
Storage/Retrieval 
System 

Tape  Cassettes 

Activity -Model-Name 

ITAP 

ITAP 

ITAP 

Performance-MeMure-Name 

Document 

Retrieval  Time 

Document 
Retrieval  Time 

Document 
Retrieval  Time 

Improvement-Opportuoity-DeBignation 

Eliminate 

Handling 

Eliminate 

Handling 

Eliminate 

Handling 

Initiative-Designation 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Increase 

EDMICS  User 
Community 

Component-Name 

DLA 

DLA 

DLA 

Oganization-ID 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

Defense  General 
Supply  Center 

FuoctKmal-RetjuirementrDesigoation 

On-Line  Access 

On-Line  Access 

On-Line  Access 
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